1

I have an application I am working on, using Entity Framework 4.1 as my data access layer. I have created several repositories that work with different entities. Each repository, as part of the constructor, takes in a UnitOfWork object. I then created an abstraction to those repositories with services layers. Each layer creates a UnitOfWork that is then passed to its respective repository.

In my service layer, should I only be opening one UOW that can be used by all the services I have created? I haven’t run into any issues, yet, but wanted to know if what I am doing can possibly cause issues.

As a note, in my web application, I am only working with one entity type at a time when inserting an updating data. My concern came when I had to instantiate one service for the main entity and then possibly another service to read in static data that comes from a configuration table in the database.

DDiVita
  • 4,225
  • 5
  • 63
  • 117

3 Answers3

2

You can have as many unit of work instances as you need within single request processing. Unit of work represents single logical operation.

For simplicity (and in most cases it is enough) developers usually use a new single unit of work for each request because each request usually represents one logical operation. But you can find scenarios where this will not be enough. In such case you will need multiple unit of works and probably also multiple repositories (each set associated with one unit of work).

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
1

If you have multiple units of work you WILL eventually have problems, because if you try to relate an entity from one context (unit of work) to an entity from another context, you'll have a change tracker collision.

Assuming you have a business layer called .Task or some such, each Task should instantiate a unit of work and pass it into the repositories it calls, since it is the task, not the repo, which should know how entities are to be brought together.

It's ok to have a repo default a UOW by default if one isn't provided - but that can lead to lax task coding where you end up creating a repo w/o a UOW then using its output in something that has its own UOW.

Avoid one common static unit of work, as well - since again, the task, not the repo or the model, should be deciding when changes should be applied.

The Evil Greebo
  • 7,013
  • 3
  • 28
  • 55
  • My repos require that a UOW be passed in. Like you said, I don't want the repo being responsible for that. So, in your Task example, it seems I would have multiple UOW open at a time? – DDiVita Jun 15 '11 at 20:19
  • No - sorry for the confusion - say you had a task to create a user account with an associated company. Your task would create one UOW, and then use it when instantiating a repository for users and a repository for companies, using the SAME UOW for both. You'ld fetch the company you wanted, attach it to the new user, and use then add the user to the user repo. Both repos share the same UOW so there's no entity change tracker collision. – The Evil Greebo Jun 16 '11 at 13:06
1

No, you should only have a single UoW open at a time. I would recommend using a Factory to provide a single instance of your UoW per HTTP Request.

You can find a sample implementation here: Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable

Community
  • 1
  • 1
Paul
  • 12,392
  • 4
  • 48
  • 58