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.