Which layer should create DataContext?

Question

I have a problem to decide which layer in my system should create DataContext. I have read a book, saying that if do not pass the same DataContext object for all the database updates, it will sometimes get an exception thrown from the DataContext. That's why i initially create new instance of DataContext in business layer, and pass it into data access layer. So that the same datacontext is used for all the updates. But this lead to one design problem, if i wanna change my DAL to Non-LinqToSQL in future, i need to re-write the code in business layer as well. Please give me some advice on this. Thanks.

Example code

'Business Layer
Public Sub SaveData(name As String)
Using ts AS New TransactionScope()
Using db As New MyDataContext()
    DAL.Insert(db,name)   
    DAL.Insert(db,name)
End Using
ts.Complete()
End Using
End Sub

'Data Access Layer
Public Sub Insert(db as MyDataContext,name As string)
    db.TableAInsert(name)
End Sub

Answer 1

IMHO, when business logic layer (BLL) needs I/O to some store (DB, XML, disk, etc.), best way to have data access layer (DAL) out of BLL, since you may change it, you want to control caching, etc. So actually, BLL should not have DataContext, just a contract with DAL (Interfaces).

Answer 2

Being the DataContext tightly coupled to LINQ to SQL, you should definitely create it in the DAL.

Have a look at the answer I provided to this somewhat related SO question. It brings up the same problem of whether the DataContext (ObjectContext in Entity Framework) should be kept alive across multiple database operations, or it should be created and disposed of ad-hoc.

The problems you are referring to are related to the fact that model objects retrieved through a DataContext can only be updated using the same DataContext instance. Now, if the original DataContext has been disposed, any attempt to attach an updated model object to a new DataContext instance will fail.

However this isn't necessarily an issue, depending on your application's architecture.
For example, ff the model objects retrieved and manipulated through LINQ to SQL are being serialized back and forth between a client (like in a web application or a web service) than the updated objects will never be the same as the ones that were originally retrieved. In that case they can safely be attached to a new DataContext.

Answer 3

As always, it depends on your particular case, but as a good heuristic I would advise you to create/submit/abandon your DataContext (or your ISession if you're using NHibernate, or your ObjectContext if you're using EDM) in the thin facade that lies between your presentation and your business logic. This is sometimes called Application layer of Service layer.

That was where, now -- how. Another good heuristic says that you should use AOP to accomplish the task. And by AOP I don't mean a huge fat AOP-dedicated framework. Almost all presentation and web service frameworks provide some AOP capabilities witch enable you to do some work before and after the business code gets executed, for example IHttpModule in ASP.NET and IDispatchMessageInspector in WCF. Plug into you framework before and created the DataContext.

If you ever need to change your DAL, you will have to change only DAL and the code you used to create/submit your DAL changes. In fact the AOP-injectable code should also be placed in DAL assembly and, if possible, configured in the bootstrapping routine.