Linq-to-SQL Design question!

What if you n开发者_StackOverfloweed to create POCO objects from a dbml file? Do you use a generator and who? You write the POCO's manually? Say you like to make your objects Persistent Ignorant and share to clients, then create a DAO pattern for the communication between Client - DAO - L2S Objects, this is a question for disconnected design using Linq 2 SQL. Supposed that the POCO's using the client should be as much as primitive as they can be without dependencies (EntityRef<>, EntitySet<>, Attributes, etc.), and ofcourse you could cast the L2S object into the POCO with the appropriate DATA. Any help and any corrections on the concept would be really helpful!

I would be tempted to say "wait until EF in .NET 4.0", which has much improved POCO support (compared to EF current) and hopefully a POCO T4 template in VS2010.

At the moment SqlMetal will emit rich objects; while LINQ-to-SQL can work on POCO types, you would have to write the POCOs yourself, or use xslt / T4 / whatever on the dbml.

SqlMetal can emit an XML mapping file from an input DBML file via the /map[:file] switch. This removes attributes from the generated class files, which is a step closer to POCO - you just have to remember to initialize your data context instances from the XML mapping file.

Removing EntitySet<T> and EntityRef<T> references is harder, and I'm not sure it's something I would recommend as you would lose a lot of useful functionality. However, it is possible - you need to manually manipulate the DBML file that you pass to SqlMetal by removing all <Association> elements. You could do this using LINQ to XML as a custom step in your build process, for example.

This would basically disable associations in the output mapping file and classes, as SqlMetal will only generate EntitySet / EntityRef code for <Association> mappings. You lose the ability to manage parent-child relationships automatically though.

That would give you a pretty close POCO pattern - the only other thing you would get is the INotifyPropertyChanging implementation, but I think you could justify hanging onto that as it is fairly generic.

If that doesn't meet your needs then you could look at doing your own code generation - check out T4 templates for LINQ to SQL which works in VS 2008 and is based on SqlMetal, but you have the option to totally customize the output to suit your needs as it uses T4 for template specification and output generation.

We also use Linq2Sql and need to write own model classes from L2S results. After lot of googling I've found T4 POCO Templates for Linq2Sql and EF which uses .dbml or .edmx files as a source and create own POCO entities. Link to download at the bottom of the article or duplicated here. We used it as a base and then customized it for our needs.