Unplugged LINQ to SQL Generator

As several smart guys already pointed out,  the LINQ to SQL (LTS) package as it is doesn't always fit well in an N-Tier architecture. On this topic you may read Rick Strahl 's early post on "LINQ to SQL and attaching Entities" and Nick Kellet's review on Planet Moss: LINQ To SQL ≠ N-Tier Architecture?

The RTM version offers a way of detaching thru serialization and re-attaching thru the Attach API for the frequent scenario of Web Services / WCF distributed apps. And even some capability of serving "non tracked" objects thru the EnableObjectTracking data context property.

But in my opinion this is not good enough for building an "all-terrain" business layer, serving disconnected DTOs which may be either light-weight POCOs or more complex entities with stand-alone change tracking, in the same way the good old dataset allows. A discussion on this topic can be found in Benjamin Eidelman previous entry.

That said, it's also palpable that many of the tools in the LTS bag are just too good to be ignored. So maybe the key for a successful adoption of this technology is to have a clear understanding of its pieces and combine then in the way that best serve your particular scenario.

With that in mind, we started by manually coding entities to replace the ones generated by the LTS custom tool (MSLinqToSqlGenerator), and we come across a couple of interesting conclusions:

• The Data Context class does not need to have strongly typed table properties for making the queries: a generic data context may be used, and invoking GetTable<yourEntity>() provides the virtual collections on which LINQ queries are based. This allows us to break the awkward coupling of DC and entities in a single (big) DBML file, and take a more flexible approach.
  
  
• Almost any class decorated with the right LTS attributes is able to be used as a query entity, even pure POCOs (Plain Old CLR objects). The default classes, closely tied up to the DC by notify events and EntitySet collections, are not mandatory for using the power of the LINQ provider in LTS.

At that point we decided we wanted to develop our own custom tool for translating the DBML build by the O/R designer into our own entities code. As we intended our classes to be detached from the DC by design, the name "Unplugged LINQ to SQL Generator" was an unanimous decision.

So we are walking that path. The first release of our custom tool, a proof of concept with limited capabilities, was published today as a Code Plex project: http://www.codeplex.com/ULinqGen .

Stay tuned! More to come soon...