How LINQ compares to EJB and others

This isn't directly interop-related, but it is interesting enough to warrant mentioning.

A new paper on MSDN , written by Ted Neward, examines Microsoft's LINQ (Language Integrated Query), and how it compares to other frameworks and approaches to mapping Objects to Data. The big difference: with LINQ the focus is on query, whereas in EJB (even EJB3) and many other previously-proposed frameworks, the emphasis is on the OR mapping issue.

Look, the task of mapping objects to a backing store is important and can be complicated, as anyone who has built large domain models can attest. But, we're starting to find a balance point in O-R mapping, maybe even some sanity. Code-generation approaches have helped (CodeSmith has a good offering), as have general-purpose persistence frameworks (like Hibernate or nHibernate and many commercial options), and combinations or supersets of those, like LLBLGen or DeKlarit. The willingness to relax the purity standards and consider and employ Table metaphors where they make sense also helps (see Fowler's PEAA, pg 127) We learned that the object-based approach of EJB didn't do well with large data sets, and dynamic ad-hoc query. Fowler mentioned "considerable programmatic gymnastics", but really it's just way too much work for what you get out. We learned and progressed. We're getting to a point where developers using modern tools can solve the business issue without needlessly (hopelessly?) pursuing purist OO solutions. Which is good.

Beyond O-R mapping, being able to integrate query and relations into a mainstream language, like VB.NET or C#, is pretty novel. It means a developer can extract relevant subsets of data from an in-memory set, without relying on an external query engine, like a database server, or lengthy boilerplate iterative loops and searches. This is one of those fundamental changes, like automatic garbage collection or JIT-compilation. Five years from now, we'll look back on this and wonder how we ever accomplished anything without it.

Comments

• Anonymous
  December 22, 2005
  Great post. I'm kind of curious what kind of prescribed architectural standards there will be (and the various opinions) on where DLINQ queries should live. Obviously if you are passing results in the form of object/collection/object-graph downstream anonymous types aren't going to do us much good. Don't get me wrong, I've been impressed with the previews of DLINQ and I use LLBLGen Pro, so I'm open to whatever solutions work best. But at the same time it seems like a leap of faith for someone like me who is very comfortable writing complex SQL statements to invest in DLINQ. Also, I agree with Fowler's "considerable programmatic gymnastics" remark regarding dynamic ad-hoc queries. I've found my self on many occasions working with the LLBLGen object model for 3x longer than it would take for me to write a friggin' SQL statement to do the same thing. :-)