NHibernate : Object Relational Mapping Coolness

I haven’t been around every block, but I have seen many ways people have cooked up mappings between a persistent layer, typically a database, and some sort of object model, whether a business oriented domain or just a bunch of objects.  Probably the worst I’ve seen has been data classes with methods like Select(), From(), Where(), Group() and bits and pieces of dynamic sql spilled all over.  It was impossible to follow or comprehend.  I’ve seen other approaches, including myself, that is ordered, neat, and works well, but isn’t something I’d call great.  The concept of object to relation database mapping isn’t new, so when I started looking at some of the frameworks out there, I said to myself “why haven’t I been using this sooner?” One ORM in particular that caught my eye was NHibernate, which is a port from a ORM in java called Hibernate.  It’s got a bit of a steep initial learning curve but once you got this engine firing on all cylinders, damn this stuff is cool.  One of the core concepts that really caught my attention was that fact that NHibernate stresses domain driven design.  In a nut shell, forget about the storage of your data objects and focus on what you business model is and how it works; deal with the persistence later because that’s what the “mapping” part is all about.  Of course there is a bit of give and take because you might be trying to use this ORM with a legacy database system that doesn’t easily fit into a nice domain model.  Also, NHibernate doesn’t solve all the database mapping scenarios, although I would say it could follow the 80/20 rule: it will solve 80% of the most common scenarios, leaving only 20% to some other type of technological solution.

Anyway, I’m not going to give a full demo of how it works, there will be links at the end of the post that can get you started.  The following 4 items are all that is needed to get up a running:

1. Some domain model with a mapping to a persistent layer (i.e. a database).  The mapping can be done a few different ways, but the concept is that you indicate how your objects will map to given database tables/columns.
2. Enter the correct app.config settings.  The configuration settings tell NHibernate information like what type of database it’s talking to and how (i.e. SQL2005, MySql, Oracle, etc).
3. Generate the session factory in you app, preferably only once such as a singleton.  The SessionFactory is in charge of generating proxy classes for you mappings.  If you get stuck by why properties have to be virtual on some of your mapped classes read this.
4. Use the session object to interact with the persistence layer.  The Session is the item used the most, it’s kind of like a database connection/command in that you have to open it and commit stuff and close it when your done, but that’s as far that analogy goes.

It’s amazing how much time one can save on the mundane tasks of persisting your hard work you put into your domain model.  This is the biggest selling point for me, as importance of your enterprise application isn’t general how you going to save data object but how do these data objects relate to each other.

Good book: NHibernate in Action

Example sites:

Using NHibernate with ASP.NET 2.0 site

Simple Example Using Test Driven Approach

AutoComplete Extender Word Wrapping

Recently I’ve been working with the ASP.NET AutoCompleteExtender control.  It’s a pretty nifty way to quickly get an auto complete input on you web forms.  Unfortunately there are some annoying behaviors that can really get on your nerves.  One such issue is word wrapping when your results are wider than your input control.  The client had these auto completion names that were more than 100 characters long; this made the list word wrap, and it looked absolutely terrible.  Luckily there is a clean way around this using some “important” css!

1) Set the property AutoCompleteExtender.CompletionListElementID to a DIV that is placed right below the control that will have the auto complete and set the css class, such as:

<div ID="autoCompletePanel" runat="server" class="autoCompleList"></div>

2) In a css style sheet, define the following class.  Notice the use of the css !important.  This forces the rendered auto complete data to not word wrap.

.autoCompleteList {
    width: auto !important;   
    overflow: visible !important;
}

3) If you want to customize and add extra styling you can override other properties that are placed on the elements inside your auto complete. Each item in the list is rendered in it’s own DIV.

.autoCompleteList div {    
/* Any extra styles you want to override */
border: 1px dashed buttonshadow;
background-color: window; color:
windowtext;
cursor: default;
width: 130px;
position: absolute;
left: 184px;
top: 27px;
display: inline;
}

 Other auto complete implementations: 10 Auto Complete Ajax Scripts

.NET Remove Xml Documentation Compile Warnings

One of the nice features of Visual Studio is the ability to quickly add code documentation. Using tools, such as nDoc, you can create help files in many formats (MSDN style, chm file, etc.). This is great for large operations with lots of code, because it aids new and old company developers in finding code and understanding what the code does. One way to enforce the usage of the XML code commenting is to turn on the "XML Documentation file" setting in the build properties (C++.NET does not work). The setting can be good and bad. The bad part of this setting is that it forces you to comment everything, such as over obvious enums, etc. If your satisfied with the commenting you have, but yet get tons of compiler warnings "Missing XML comment for", you can turn this off by using the "Suppress Warnings" property in the build attributes. Add the warning 1591 and it suppress these warnings.