Joel Hainley

I’ve been working on a project in .NET 3.5  and  Adobe Flex 3 and have been having a good time getting the base architecture in place. I’ve spent the last couple of weeks looking at two ORM technologies available in .NET. NHibernate and LINQ for Entities. 

I started started out working with NHibernate because I was familiar with Hibernate in the java world. Well actually, I was familiar with the Repository from ATG which is pretty similar to Hibernate. (My general impression is that ATG’s Repository is a bit more polished than Hibernate) NHibernate worked out great and very quickly I was able to get the database access up and running and had a working prototype. Once this was done, I did some more digging to see what other ORM implementations were available for .NET.  There are quite a few projects out there but I came across LINQ, and specifically LINQ for Entities.

LINQ could probably best be described as a generalized approach at data access from various datasources that is intended to replace all of the customized query languages/approaches ( SQL, XPath, iteration through various collection classes, etc ) with a single language. Ostensibly this will reduce the amount of stuff a developer needs to know to be effective. According to the available documentation LINQ for Entities is the most customizable implementation of ORM functionality available in LINQ. There are some other ways to do similar things with a little less control using LINQ to SQL but I decided to just dig deep as the sort of control I was used to with Hibernate was most similar to LINQ for Entities.

I had to upgrade Visual Studio 2008 to sp1 to use LINQ for Entities, but this was trivial and I soon had things up and running. In short order I had everything working with LINQ and the application was moving forward again. At this point I’m mostly impressed with LINQ and I think I’ll end up using it for this project. There are a bunch of tools available in the IDE to support the mapping operations, and it will autogenerate initial classes by simply pointing the IDE at the database you are using.

I’m not sure if LINQ is the be all end all that microsoft is hoping it will be. I’m not convinced that a generalized query language is needed. It has been said, by several philosophers and more than a couple of programmers, that the language that you have available to express yourself has an impact on your thinking. In this case specialized languages such as XPath and SQL give your mind a set number of ways to express yourself that are consistent with the underlying implementation. Yet a generalized approach abstracts that away and removes you another step farther away from the realities of the toolset you are using. Is this a good thing? Time will tell and at the very least it will be interesting to see how far people can take this approach to querying various datasets. 

The thing I am convinced about is that ORM technology is making it much easier on developers to quickly and easily get database code up and running. The increases in productivity are real. It is nice to interact with the data as objects instead of as sql queries, stored procedures, etc. Somehow I suspect that the Smalltalk crowd is sitting in the wings chuckling at all of the other technology platforms touting their ORM solutions.