LINQ to SQL entity and data-context classes: business object encapsulation

Question

What are your favorite ways to encapsulate LINQ to SQL entity classes and data-context classes into business objects?

What have you found to work in a given situation?

Have you invented or taken to any specific patterns?

Answer 1

Right now I'm trying to use LINQ to SQL entity classes as business objects, to pass them around between functions and services.

Of course, you should have separate entity classes for database access, so your database layout can change without changing the business objects!

I'd be most interested in a good solution for this, too!

Answer 2

I did some experimentation using Entity Framework and Linq to Entities as a way to further separate my client code from the database, but I found it clumsy to use and was worried about the performance.

In my current project I use Linq to SQL as my data layer, but have separate classes where I implement all Linq queries. The classes return entities defined in my Linq to SQL context, but the queries are hidden in methods.

Answer 3

Check out the source code for the MVC Sample app that Rob Conery is putting together:

http://www.codeplex.com/mvcsamples/

He has a separate entity layer that maps to the LINQ to SQL classes.

Answer 4

I tend to use the Repository pattern to encapsulate DataContexts.

Repository Pattern

I would like to find a better way to emit POCO objects from my data layer while using LINQ2SQL though.

Answer 5

I found the articles by Ian Cooper on CodeBetter.com and Stephen Walther series invaluable in understanding the need to write the POCO entities first and then map them to the database rather than doing it the other way around (which is what I always used to do).

Answer 6

I'm playing around with the idea to have a separate layer of OO model (better support for OO practices), but that use LINQ to SQL under the hood. The idea is to have an xml file that a custom tool will use to generate the code. Since LINQ to SQL entites are too cluttered for my preferences, I will auto-generate new classes to use as my entities and of course the DataContext will be completely hidden for the client code. Do the short answer is: Create new entity classes but use the underlying LINQ to SQL entities and DataContext.

Answer 7

I just published a sample of how you can structure your application that uses Linq to Sql for storage, using IoC and T4-templates.

http://daniel.wertheim.se/2010/03/14/linq-to-sql-how-to-separate-the-entities-and-the-datacontext/

//Daniel