Which layer should host the LinqToSql entity files - In My Case

Question

So i looked around a and didn't find anything that quite looks like what i'm talking about, i know some are similar but this is a more specific question.

I'm working on project at home and using the entity framework as my ORM provider, when we work on project at my workplace we use NHibernate and have different DLL's set up for DM \ DAL \ BL etc.. where the actual mapped classes and hbm files are set up in the DM folder and the DB connection occurs only at the DAL layer, all the projects have access to DM and use the models to move stuff around, i.e UI->-(WCF)->BL->DAL and back again.

My own project has a similar set up, however when I got to actually using EF to map my database and seeing how it works, it seems that wherever I generate the classes the DB connection must exist as well.

So my question is where should I position entity classes and DB connection? or is there a way to separate the two and still easily generate the classes via drag n drop?

Thanks in advance!

Answer 1

This is a fairly common question. With ORM's like EF and LINQ to SQL, the real "DAL" is the ORM layer (it's what does the actual data-access heavy lifting). Yes, connection information like the connection string does exist at the model level, but that sort of information should be coming from the bottom anyway, so that shouldn't be an issue of any real consequence.

So, to answer your question, just put the ORM entities in their own assembly and start working.

Answer 2

Depends also on how 'purist' you intend to be with the Entities - if you have multiple in-memory 'views' of the 'data' (e.g. DAL DTO's, Business Entities, DataContract type entities across the WCF Wire, and ViewModel data for the UI etc) then leaving the 'DAL' entities in the DAL assembly is fine.

However, a common quicker and dirtier solution would be to reuse POCO's across all tiers (as per Adam) - splitting these out into a separate assembly and then reference the POCOs from any layer.

AFAIK with Linq2SQL this isn't possible since the entities are tightly bound to the DataContext (meaning that all layers using the LINQ2SQL entities would need to reference the 'Dal' - not pretty at all)