Let’s start with some basics. Object Relational Modeling has been around for quite some time. The work by Dr. Raymond Chen has informed the design process of ORM systems for almost 30 years now. I posted 3 years ago that even Microsoft based its own decisions on the work of Dr. Chen.

Fast forward 3 years and it seems that many MS shops think that Business Objects, or ORM, in .NET 3.5 requires Linq.  Far from it. There are other, potentially more rewarding ways of doing ORM in .NET. Two prominent and mature alternatives on the market  are NHibernate and LLBLGen.

I should qualify one thing right up front: Linq tries to be more than an ORM tool. By definition Linq is “ a set of proprietary query operators that can be used to query, project and filter data in arrays, enumerable classes, XML (XLINQ), relational database, and third party data sources “

In short, Linq is more than a typical ORM mapper against a database. That is its strength and also potentially its downfall when compared to ORM mapper. While I personally think its great to use Linq to query things like Directory Structures or Strings, I also personally think that both NHibernate and LLBLGen are better at ORM – much the same way that SQL Server is better at managing data than say an XML document. Specifically, for example, Linq requires a developer to jump through some hoops when lazy loading an object graph. In addition the query tree expression generation code that Linq employes makes some odd decisions on occasion. That can lead to severely slow query performance.

As it stands, Linq is the 800Ib gorilla in the room because it originates with Microsoft. That means developers need to be able to work with it and the third party tool market has to cater to this by potentially adjusting its products to work with Linq.

Linq is extensible via a Provider pattern that implement the IQueryable<T> interface. A quick search of the Internet brought back examples of providers for CSV, OpenMapi and even Twitter. But writing a good Linq provider is no picnic at all. Many providers on the market today only cover a subset of the Linq spectrum. Writing a full-fledged Linq provider has taken one of the best programmers in the business almost a year and it is 1.2MB large. That should be a caveat for anyone contemplating that this is an easy task.

While Linq as a technology wants to be more than just an Object Relational Mapper for databases, both NHibernate and LLBLGen are exactly that and don’t try to be anything else. As a matter of fact, in the big scheme of things both tools are “closer to the metal” than Linq.  So much so that both tools offer a Linq provider that allows a developer to run Linq against NHibernate or Linq against LLBLGen. In that manner both tools broaden their market scope and build on the knowledge that developers have acquired when coming to the ORM space from MS centric projects. I am told by users who have tried the NHibernate Linq provider that it is still a bit immature at the time of this post. This just underscores the difficulty of writing a good one.

What then is the difference between NHibernate and LLBLGen? As far as I am concerned the differences fall into three large areas:   product philosophy, developer productivity and vendor quality / product maturity .

Product Philosophy:
NHibernate approaches the concept of building entities and mappers from the stand-point of designing business objects first, without any regard for databases or persistence structures at all.

LLBLGen, on the other hand, adheres closely to the work of Dr. Raymond Chen mentioned earlier. It builds entities on the basis of a database schema.

The tool of choice here really depends on how you approach the ORM space. Do you prefer to work with objects first and disregard persistence? For the time being NHibernate makes that easier than LLBLGen. I should point out that the next version of LLBLGen, due in a few months, has one incredible advantage over the competition – it will support Model-First development. By encompassing both design philosophies the LLBLGen designer tool – which by the way is the only fully functional designer tool in the ORM market – will cater to both camps. Essentially LLBLGen will allow you to work with NHibernate files, its own providers as well as Linq. Its a win win win situation.

Personally I have always worked with the db first approach.  I understand and sympathize with the object first approach. But the majority of my larger projects have existing databases. For instance I can’t very well insist that Chevron change its db structures, just to accommodate my ORM system.

LLBLGen makes work with existing data structures a breeze. Unlike NHibernate it supports multiple databases within one project, foreign key relations, prefetch paths and typed lists

As a side note, if you want to learn more about the object design first approach I recommend Jimmy Nilsson’s book “Applying Domain Driven Design Patterns”.  It’s a fantastic work on that subject.

Developer Productivity:
LLBLGen runs within a  separate development IDE (not within Visual Studio) and is by far the more productive tool. Turning a database into entities and using them in a project requires but a few clicks and option selections.

In NHibernate the developer is asked to hand code empty business objects (usually POCO’s) , then  manipulate an XML mapping file. I realize the typical argument here is to point out that this approach offers more control to the developer. Yes it does.  But the fine grained approach impacts productivity whenever changes need to made after the initial design. Especially with larger projects the need to work at a fine grained level can become cumbersome. After all the mapping files in NHibernate do not live in a vacuum.

A couple of years ago I had the pleasure of watching a longtime Hibernate architect become completely addicted to the productivity of LLBLGen. He literally was blown away by how much he could accomplish in very little time. In the end, the formerly dreaded change / update cycle became one of his biggest tools in being productive. My colleague took part in building one of the larger real estate loan processing engines in the US using Hibernate and Java – he knew those products inside out.

Vendor quality / Product maturity:
If you are faced with a tricky medical decision, whom would you trust more – a GP who deals with a variety of medical issues or a specialist that eats,  sleeps and breaths the specialty you need?  In other words if you can see the quality of the people whom you trust would that help in your decision process? It does in mine.

How smart are the people behind the tools you choose? In the case of LLBLGen and NHibernate I’d say the development is headed by a couple of programmers who are absolutely the best in the field (Ayende Rahien and Frans Bouma).  Contrast that to another ORM tool on the market – the MS Entity Framework and its problems over the past three years and you can see how essential the capabilities of the core devs in a tool like this really are.

Both LLBLGen and NHibernate are mature within the marketplace. NHibernate builds on its “big brother” Hibernate for Java.  While NHibernate is a failry mature open source project, LLBLGen is the most mature commercial tool of its kind in the .NET market.

Open Source projects are great in many ways – especially after they have settled down a little. But as a personal choice I will frequently pick a good commercial product over an open source one. There are several reasons for that. When your reputation is on the line with the projects you implement, its good to have a person who is directly responsible to you by the fact that you paid for their product. Granted with some vendors that’s a useless measuring stick but in a comparison between NHibernate and LLBLGen, I favor the latter because a very specific person is responsible for the performance of the product.

Overall there is a great sense of design and continuity in the product. I have used it since 2003 and I am here to tell you that in 6 years, through dozens of commercial projects for a raft of important customers – from Chevron to ITT Corp and Chrysler; from Lycos to Gameshow Network – accounting for several thousand man-hours of work it has never let me down.

Since this is not a product review I would urge you to visit the llblgen website and have a look. Features like visual inheritance definition, non-overwrite of custom code, support for all relationship types (1:1 ; 1:M ; M:1 and M:M) and much more can be reviewed there. And of course take a look at the NHibernate site as well. There is much to like in both tools. As it stands when someone asks me “Linq or NHibernate” I am very likely to answer “Neither my friend… but let me tell you about the tool that you should use ! ”

Update:  10-31-2009 – I just had to include Mohammed Meligy’s post because his experience parallels mine. Here is a link.

My main issues with MS MVC is the fact that it tries to be something very similar to RoR. I feel this way because Model View Controller can be done without MS MVC. As a matter of fact as I have mentioned ad-nauseaum Dan and I have built and MVC driven framework a while back. So if I am interested in just the simplest most straightforward way to plug MVC into ASP.NET – thats the way to go – just build a small and simple action framework / router. No tag-soup either. I suppose I have to revisit this after ASP.NET 4.0 is out because it will incorporate routing.

Having said all that as a preamble, I would be silly not to study up on MS MVC. There are some aspects I really do like about it. The great enforcement of separation of concerns for starters.

As I looked over the web to find some decent examples of people who have blazed trails in this area I came across Karl Seguin’s Canvas MVC sample app. It was written with one specific purpose in mind: as a simple learning application that illustrates a good way to build an MVC app. In my opinion this app is a resounding success. It has enough code to illustrate the majority of work that one has to deal with (i.e. data entry, paged lists etc). And it doesn’t try to throw every possible scenario in the mix. The result is a well structured easy to follow sample. Believe me I have looked at numerous different ones out there and this is by far one of the better designed samples. Love it !

Speaking of interesting, Rick Strahl came across yet another one of those WTF scenarios with LINQ. Apparently it manages to create circular references when you try to serialize objects. That’s so lame its unbelievable. What I do not understand in all these issues that LINQ seems to have (and unless I am mistaken that the Entity Framework also has here and there) – what I really don’t understand is the fact that ORM has been around for ages. Entity Relations were first defined in the 70’s by Dr. Peter Chen. How is it that the Architecture Astronauts at MS can’t get their act together and produce this stuff without numbskull problems like this.  I have long since given up on completely problem free releases, but some of the recent technologies that are being evangelized seem to have a higher than normal quotient of WTF errors.  Is it any wonder there are a number of dissatisfied voices out there.

Luckily in the case of ORM tools there are a number of viable commercial and Open Source alternatives available.

UPDATE: And if you really want something to make your eyes roll back in your head, check out Roger Jennings list. I especially took notice of the part where Roger mentioned that his concerns were pretty much ignored on the forum. Now folks, Roger goes way way back in the database world. If MS simply ignores the comments of a thorough and conscientious developer like him… imagine what else gets skipped, ignored, shuffled under the carpet and overpowered by marketing and evangelism. I continue to say it again and again this project has a distinct smell. And yes I DO have my own agenda here.

Have you ever gotten into a situation where your customers development team uses tools that you know full well are not best of breed, but you go along with it and use them for their project because…. well they are the customer and pay the bills. I have precisely such a case. The customers dev team requested that we use MS Enterprise Blocks for logging and exception handling. Primarily because thats what they have standardized on, and its easier for them to maintain this code if it contains the MS blocks.

Now normally we use Log4Net. Want to know why?

For starters its open source. And secondly its better built and faster.  Here is actually some empirical evidence how much faster it is. In this test it took Log4Net about 40ms to log 1000 messages while the Enterprise Library took a whopping 9500ms. That’s pretty incredible isn’t it.

There is an old saying. Don’t know where it comes from, but it goes something like this : ” Whose bread you eat – whose song you sing”. Meaning the customer is paying for it and if they like this tool we will implement it. Even if it is a bit of a pig and slow.

Of course there is plenty of discussion of the code and design quality presented by the EntLib.  Oren Eini set off a huge discussion in March 2007 when he called the Patterns and Practices group on the carpet. In spirit and meaning that wasn’t all too different from this post by PluralSight all the way back in 2003.

Face it, its very hard to turn a sows ear into a purse.

You know, I haven’t used any of their stuff since the original DAAB back in 2003 or thereabouts. Once I started to work with ORM’s and once there were some valid .NET OSS projects out there I never looked back.

Just for reference ( since I will need it in the near future ) here are a couple articles on configuring MS Blocks for Logging.

http://www.devx.com/dotnet/Article/31463
http://www.cubido.at/Blog/tabid/176/EntryID/33/Default.aspx

If you are anything like me, you hate having to read other peoples code. OK, maybe hate is putting it strongly. In as much as you have to get into another persons head and try to understand their design and thought process, becoming thoroughly familiar with someone else’s assemblies tends to be a bit of a chore. Agreed?

During the past six weeks I was asked to review two different projects done by two very different teams, in order to provide some architectural guidance and feedback. So when I tell you that NDepend is very helpful, I speak from actual practical experience.  In both cases NDepend 2.0 clued me in to problem areas that I would not have found on my own without expending considerable effort and time. Don’t get me wrong, a tool like this should not take the place of your discerning eye. Instead it should -and does so admirably – act like a sieve that runs through a codebase and provides pointers and feedback.

Typically I’ve used NDepend in two different ways. First and foremost,  I really like the comprehensive summary of findings to get a feel for the “lay of the land”. This report is usually my starting point. It highlights a number of interesting statistics, along with links to their explanation. For example uncommented code versus commented code, methods with too many parameters and various types of coupling. 

As useful as the summary report is, I found the drill down capabilities of NDepend absolutely staggering in its depth and capability.

Once an analysis run has been completed, you can drill into any assembly and gain useful information at the level of namespace or class or method. I’m sure I am leaving something out here. Nonetheless, the point being that NDepend can be of invaluable service if you have to consider refactoring code that was written by someone else.

During my two code reviews, it helped me to quickly provide feedback to my customer, that outlined areas of concern and the potential impact of refactoring them.

And just in case one of the many, many built in metrics and analysis points do not cover your needs, Patrick Smaccia (NDepends author), has had the foresight to include a way to query the information accumulated in an analysis. He calls it CQL – Code Query Language.  With CQL you can write statements like this – very similar to SQL 

SELECT METHODS FROM ASSEMBLIES “System” WHERE IsAbstract

SELECT TYPES OUT OF NAMESPACES “System.Windows.Forms” WHERE IsUsing “System.Windows.Forms.Control”

If needed, NDepend can be integrated into the build process, similar to the way one might run FXCop. If you have to supervise the code production of a team, then having NDepend flag potential problems for you after a build give you the ability to react faster and address the area of concern before it is forgotten or overlooked.

One of the aspects I especially found useful was NDepends ability to display a nice code diagram in its summary report. This visual aid helped me to quickly find my way around. The sample picture here was taken from an unrelated project.

There is truly a lot of information coming at you when viewing the results of an analysis in Visual NDepend. It took me some time to make sense of this almost overload, but once I got the idea I was very much like the proverbial kid in the candy store.

Click to enlarge.

Along came Object Relational Mappers. Be that NHibernate or commercial ones. At its core, the ORM among many other very useful things, provides a way to quickly and relatively painlessly abstract your code away from its database. Therefore – and this is important – you can write an application against one database, then swap out back-ends for another database and with a minimum of changes be up and running in no time. One of the best examples of this was watching my buddy Dan change an ENTIRE learning management system from SQL Server to MySQL in next to no time. I think he said it took less than a week.

So I ask you, if you are MS and you see an upsurge of tools that allow developers to do this. And there is more and more buzz in the various blogs about ORM’s and the benefits of other technologies, like ActriveRecord, MVC etc etc. What would you do? Based on 15 years of watching MS, I believe the embrace and extend methodology will be applied here with great success. In the end I suspect MS will provide something to the dev community that looks and smells a little bit like an ORM but under the hood it will be just a tad different, making it easy to use with MS Tools and through its very usage making it hard to switch databases, effectively negating one of the core points of an ORM.

With everything you know about MS… doesn’t that seem like a reasonable idea? No wonder some people have begun to call the MS Entity Framework a persistence mapper not an object relational mapper.