Fantastic!

Don Eddleman Principal Enterprise Architect Healthways

We use Confluence and have found it very useful for sharing standards and information that change frequently and hence needs a collaboration environment. Its also very useful to put tips, techniques, install guides, etc. orgnaized into spaces to make it easy for people to find content. I would still opt for a content/document management system for published sites or legal documents and so I think both have their place in an enterprise. However, if I were a small company, I'd probably just get by with a wiki.

Don Eddleman Principal Enterprise Architect Healthways

There are many orm tools that are nothing more than simple mappers, code generators, or some combination. Much of these leaving you wishing you didn't drink the coolaid. However, tools like nHiberante provide transparent persistence (really the only type of ORM to purseue in my opinion) with multiple mappings patterns that don't require code annotation, code generation, or code injection. Additionally, these tools usually provide many deployment options so you can optimize your usage but provide more flexibility if needed. The learning curve is not a stroll in the park but certainly isn't Mt. Everest either. The most complicated things are 1) learning the concepts (sorta like a procedural person moving into the object world) 2) Project setup (can be simplified by providing a bit of framework code that handles setup and configuration and a GUI tool for those that don't like twiddling in xml for the mappings). 3) Using the correct design patterns to simplify usage and correct separation of concern in the application. Every place I have been, there have been those that thought a code generation, hand coding, or some wrappers on top of DataSets was faster, better, etc. Every time, I have shown that projects came in 30% faster with fewer bugs in the persistence layer and were able to accomodate late stage changes that wrecked the similar endeavor on another project. Finally, an ORM is always the right method for all forms of access to a database. If you have complex queries or a need that's best done in the database then most certainly you should hand code that since the goal here is not to replace the developers intelligence but instead focuse that intelligence on the business problem and not plumbing code.

Don Eddleman Principal Enterprise Architect Healthways

I usually have an abstract ModelBase class that contains not only an ObjectId but a VersionId. The ObjectId is the persistent identity and the VersionId provides support in optimistic locking and support for maintaining history when needed. When these are mapped by a concrete domain model class, The ObjectId does map to a column called ObjectId which is the persistent identity of the class. If the class wants to provide a more natural alias like FooId for Foo class then defining a property that just returns the ObjectId works nicely. If an object also has a business key then that is represented and stored too. For example, it is sometimes the case that some business domains want a natural (human-readable) key to identify instances of a particular class like Product. The key for me is not to use that key as the system key as it couples different concerns and if the company decides to redo how they identify their products you’re not hosed at the database level. In terms of foreign keys, I find using the Name of the table followed by ObjectId most useful. For example, given Foo and Bar, a relationship from Bar to Foo would have FooObjectId in Bar table that is the foreign key to the ObjectId in Foo. This not only indicates that the relationship is a system key link but what type of object is related (what you need to know).

Don Eddleman Principal Enterprise Architect Healthways

Both Hungarian and use of underscores have their roots in C espeically those of us that lived in a flavor of unix. Amongst the development community I worked with in the late 80s, we used underscores to avoid name collisions between file scope and local variables. We used Hungarian notation to add type and pointer details to variables especially those defined as extern. With the advent of Object-Oriented programming and the concept of encapsulation, the need to know the type essentially became less useful and besides, as those that lived through maintenance of such code, misleading or erronous. From what I have seen, the use of underscores or prefix styles is usually done to avoid name collisions between class field/member declarations and parameter names that might be used in methods or constructor parameter lists. My opinion is that there are better means to do this by either avoiding the collision or use of a qualifying this. to scope to the correct member. Hence, I do not find use of prefix or underscores useful but can live with them if used consistently.

Don Eddleman Principal Enterprise Architect Healthways