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.