I'm on vacation and am sitting in a coffee shop catching up on some blogs.  Sergio Pereira posted the other day his praises of the new crop of .NET screencasts.  His post explicitly calls out Steve Bohlen and his Summer of NHibernate series.  I wanted to echo Sergio's sentiments about the .NET screencasts and in particular Steve's new series.  I have used the quiet evening in the cabin to watch the excellent videos that Steve Bohlen has put out.  The quality of the videos both in production and content are unsurpassed.  I've used NHibernate before but this is a much better primer than reading a few blog posts/tutorials here and there when a roadblock is hit.

If you've not seen these videos yet and are looking for a good introduction to NHibernate, check out the Summer of NHibernate series.  When you do, make sure you donate (at least a dollar).

Last week I blogged a about Unappreciated Open Source projects.  In the post I made a commitment:

From here on I've resolved to donate a dollar any time I download a free library or webcast where a donate link is presented.  Why $1?  In all honesty it is something I can commit to.

I'm thoroughly looking forward to watching the Summer of NHibernate next week while on vacation.  As I was downloading the videos I came across the "donate" link so I whipped out my Paypal account and made good on my promise.

A few days ago I posted about our frustrations with LINQ to SQL and that it was not impressing me.  After a few days and far too much time devoted to figuring this framework out, we've abandoned our attempts to use LINQ right now.  It was far too difficult to manage entity objects with it and relations, in fact we experienced the same frustration attaching our entities to LINQ to SQL as Rick Strahl, where he aptly renamed LINQ to CLUNQ:

CLUNQ

The more I look at LINQ the more I'm coming to the conclusion that using LINQ in a middle tier - especially in a generic business object architecture - is not going to work well. There are many little problem issues that when all added up point at more problems being created than solved by the entity generation and easy CRUD layer.

Hopefully I'm just being dense and there are some workarounds for some of these issues, but reading a number of other posts on this 'detached' issue at least it doesn't appear so... Apparently even the ADO.NET Entity framework doesn't address this issue. <shrug>

 

Well...back to your regularly scheduled DAL.

Over the past year or two I've really tried to improve coding abilities by thinking on objects.  By talking about, and programming, real-world objects you can reduce the impedance with clients when discussing the problem.  I'm not alone, Karl Seguin comments about domain objects in a recent blog series about the foundations of programming:

Anyone who's gone through the above knows that learning a new business is the most complicated part of any programming job. For that reason, there are real benefits to making our code resemble, as much as possible, the domain. Essentially what I'm talking about is communication. If your users are talking about Strategic Outcomes, which a month ago meant nothing to you, and your code talks about StrategicOutcome then some of the ambiguity and much of the potential misinterpretation is cleaned up. Many people, myself included, believe that a good place to start is with key noun-words that your business experts and users use.

While looking at LINQ over the last few days I've become disappointed to find out that many-to-many relationships aren't supported.  Sure you can hack you're way around it, but anyone can hack their way around anything.  If you question whether or not it's a hack, consider all the language features implemented to make LINQ work and still many-to-many isn't supported.

LINQ requires an intermediate class in order to do a join.  In the real world there is no such this as OrderProductJoin or TopicCategoryJoin, so why do I have to have that object in code?  That smells funny.

I feel the pain of Hamilton Verissimo, the founder of CastleProject, when he comments about FUD surrounding Castle.  ActiveRecord, as an ORM, has respected the domain object for quite some time while providing Many-to-Many support.  LINQ however requires an DBML file, the usage of DataContext everywhere, and doesn't support many-to-many joins.

David Hayden, respected blogger and Microsoft MVP defends LINQ to SQL but adds:

DLinq is perfect for those developers who focus on small applications and Microsoft-related technologies.

After having used both NHibernate/ActiveRecord and LINQ, the clear winner right now in my mind is NHibernate/ActiveRecord, despite LINQ having the backing of Microsoft.  ActiveRecord respects the domain model allowing you to talk about objects with a shallower learning that LINQ.