Linq2SQL, Entities: Middle Tier or Data Access Layer

Question

Folks,

In a standard 3-tier architecture, where would you put your Linq2SQL dbml file?

Is your answer the same for a ado.net entity data model?

If the dbml file is in the middle tier, then do you have a data layer?

Regards,

Brett

Answer 1

The DBML would indeed be in the middle tier. LINQ to SQL queries the data tier (your SQL Server database). LINQ to SQL would normally be in the bottom layer of the middle tier and you would not send LINQ to SQL entities over the wire (they don't serialize well).

With Entity Framework your architecture looks a lot alike, except that EF allows domain objects to be sent over the wire. Especially with new technologies (like OData) coming out that integrate well with EF.

Answer 2

the DBML should be part of the Data Layer, and not directly exposed to the Business Layer. Instead it's best to expose methods for Getting and Saving entities, and keep the interaction with the specifics of persistence kept under the covers (in this case it's Linq2Sql, but by abstracting it, you can later change to Linq2Entities, or anything else without breaking your app).

this is also a good model if it necessary to perform multiple queries and manipulate the data a bit to create your entities, or do extra work when saving (dealing with foreign keys for child tables, etc.) in that it keeps those details hidden from the other tiers.

regarding Steven's comments about L2Sql not serializing well, it's unfortunately true if you use what Linq2Sql's builder gives you out of the box. a few workarounds in partial classes cleans that up easily enough, though.