There are hardly any enterprise applications not manipulating structured information in any way. Most often this information comes in the form of business documents as structured XML or set-based information retrieved from relational databases. The .NET platform offers related but distinct API’s to manipulate this structured information. We have used these API’s to build advanced and less advanced abstractions. These abstractions are responsible to ferry information between our enterprise specific domain models and structured data sources. One of these abstractions is
Neo which is a more advanced one. It lives on top of the .NET API’s providing a run-time infrastructure for managing structured information as objects. Although it makes enterprise applications a lot easier to maintain and sometimes easier to build, it has fundamental flaws just as all the other abstractions have. The most important flaw in these abstractions is that they solve the right problem in the wrong place.
To come back to the central question:
why LINQ for SQL? It doesn’t matter whether LINQ solves the problem in the right way (this won’t make me popular with the abstraction vendors). It does however solve it in the right place: our language, Frameworks and tools.
Apparently I inspired Udi (Microsoft Solutions Architect MVP) with my post on “Applying the application layer in Domain Driven Design” to do a podcast on this topic. You can download/stream Udi's podcasts directly from Dr. Dobb’s Portal in the SOA, Web Services & XML section. Perhaps I should experiment with blogcasting my thoughts?