30

MVC 3 + EF 4.1

I'm choosing between two approaches to deal with DbContext:

  1. Instantiate in Application_BeginRequest, put it into HttpContext.Current.Items and dispose in Application_EndRequest.
  2. Create disposable UnitOfWork (kindof wrapper for DbContext) and start each controller action with using(var unitOfWork = new UnitOfWork()) { ... }

Share your experience please: Which one would you prefer? what are pros and cons for each approach?

Pratik
  • 11,534
  • 22
  • 69
  • 99
YMC
  • 4,925
  • 7
  • 53
  • 83
  • Using block approach is having some disadvantages. It causes a lot of round trips to database and misuse of transactions in Entity framework. refer http://ayende.com/blog/4775/new-profiler-feature-avoid-writes-from-multiple-sessions-in-the-same-request – marvelTracker Aug 09 '11 at 04:04
  • Why does it cause more roundtrips? One http request supposed to run one action in most cases,so if you wrap the whole action's code into this using block there would not be more database requests comparing to 1st approach. The other thing with the 'per action' approach is that you should always be aware of a scope the database might be invoked in and put the block appropriately. For example if your model contains some collection to be lazy loaded in a time View rendering, statement returning View(Model) should be inside the block. – YMC Aug 09 '11 at 18:34
  • If you use DbContext in controller layer wrap with UnitOfWork creates strong dependency in UI Layer and your database approach. Then you need a Service Layer and Repository Layer. After that if your repositories have separate UnitOfWork with using blocks that will be a problem. because each and every repository creates transactions and unnecessary database round trips. See above link for more detail. if you sure about one service call per request then you can use unitofwork inside of service method.However, It is not guaranty. – marvelTracker Aug 09 '11 at 23:56
  • It might be 2 and more service calls per http request, but all they are most likely to be in the same action method. So once you wrap them all under single UnitOfWork they share one single DbContext. Right, they might run one-by-one under separate transactions even having the same DbContext, but first approach would work the same way – YMC Aug 10 '11 at 05:48
  • What happen if one of those transaction fails ? can you revert the other or those are independent ? that is the problem. Also, your UI layer is going to depend on Entity framework if you do that isnt it? – marvelTracker Aug 10 '11 at 07:26
  • If this are separate service calls, one transaction results (SaveChanges run) does not affect other transaction. However if I need 2 service calls being under single transaction I will combine them into separate service call that manages transaction. I still do not understand what's the difference between this 2 approaches in terms of Db calls and transactions. Both use single DbContext in the end, so Db calls should be equal. Right, UI will depend on IUnitOfWork interface, but not on EF interfaces. – YMC Aug 10 '11 at 21:08

3 Answers3

18

I would suggest you use a Dependency Injection framework. You can register your DbContext as per request

 container.RegisterType<MyDbContext>().InstancePerHttpRequest();

And inject it as a constructor parameter to the controller.

public class MyController : Controller
{
    public MyController(MyDbContext myDbContext)
    {
         _myDbContext = myDbContext;
    }
}

If the registered type implements IDisposable then the DI framework will dispose it when the request ends.

1st approach: It is much more cleaner to use ID framework than manually implementing it. Further all your requests may not need your UoW.

2nd approach: The controller should not know how to construct your UoW(DbContext). Purpose is not reduce the coupling between components.

Eranga
  • 32,181
  • 5
  • 97
  • 96
  • Right, it's better to use IoC container than handling BeginRequset and EndRequest, but it still seems to me pretty close to number 1, that's why I've not even extracted it as separate approach. What is more important for me is to compare 2 ways to access and control life cycle of DbContext (=Unit Of work): first way implies ASP.NET/IoC infrastructure is responsible for it, second one is about every controller action to be in charge. – YMC Aug 09 '11 at 00:58
  • @YMC Edited answer. Your 2nd approach will introduce coupling between your controller and UoW implementation. I suggest you avoid it. – Eranga Aug 09 '11 at 01:10
  • 3
    Introduce Service Layer and inject services to Controller. Service can have many repositories and repositories depend on UnitOfWork wrap with EFDbContext. Then use DI to inject those dependencies.Then You can get the advantage of Separation of Concerns. – marvelTracker Aug 09 '11 at 03:59
  • @Eranga: Does this mean that the context only gets instantiated if a controller is called which actually takes a context as constructor parameter? For example: If I have a controller with `MyController()` as constructor no context would be instantiated, right? If two controllers get called in one single request (could happen by using `RenderAction` for example) and both controllers have a context as parameter, only one context will be created and injected into both controllers, right? The example above isn't Unity, is it? Do you know if Unity2 offers such a logic too? – Slauma Aug 10 '11 at 16:49
  • @Slauma yes. DI framework takes care of it. example uses `Autofac`. I have seen "Per request lifetime" implementation of `Unity` on [Silk](http://silk.codeplex.com/) – Eranga Aug 11 '11 at 23:11
2

We currently use repositories injected with UoW (unit of work) instantiated via service locator from an repository factory. Unity controls the lifetime this way taking the work away from you.

Your particular implementation will vary depending if your using POCO's, Entity Objects, etc..

Ultimately you want UoW if your going to be working with more than one objectset in your controller to ensure your just using one context. This will keep your transactions in check etc.

If your going to use multiple objectcontexts (ie. multiple EDMX's), you'll want to look at using UoW with MSDTC...but thats probably more than you wanted to know. In the end, the important thing is to ensure you just instantiate what you need for the controller action (i.e. one instance of the context.). I don't think I'd go with Begin_Request, you may not even need the context for every request.

Chris Yeaste
  • 21
  • 1
-1

Don't put DbContext in global.asax! :

  1. Static field of DbContext in Global.asax versus instance field of DbContext in controller class?
  2. Entity framework context as static
Community
  • 1
  • 1
Ofer Zelig
  • 17,068
  • 9
  • 59
  • 93
  • 3
    The OP said nothing about putting the DbContext in a static field... he wants to put it in HttpContext.Current.Items, which is perfectly safe as far as I can see – Thomas Levesque Aug 08 '11 at 20:36
  • I did not say I put DbContext into global.asax. I said I put code that instantiates and disposes DbContext. DbContext is in HttpContext.Current.Items. It's thread-safe. – YMC Aug 08 '11 at 20:38