0

I am currently working on a n-layer architecture with the following layers

  • View (ASP.net Web App)
  • Manager (orchestrating Services)
  • Service (Business Layer uses Unit of Work )
  • Repository (Data Access)

For now the Manager is calling one or more Services to access the data, save data or do some other business. The Service is using the implemented unit of work and the repository so that a service is used within a transaction.

Now we have a Manager which need to call different Services which all together should work within a Transaction.

My opinion is that the Unit of Work call should be keeped in the Service as the Service is accessing the Database by using the Repository. If we move the Unit of Work call to the Manager it would broke the design. The Manager would need a Reference to the Repository.

Any advise how to design the access?

Thanks!

Rayk
  • 63
  • 8
  • Can't you just use another service to orchestrate services to replace the manager? that way the orchestrating service can hold the unit of work... – Yves M. Aug 08 '12 at 14:07
  • the architecture is build with the approach that the Manager is orchestrating mulitiple services. so there is no need to allow services to call other services. – Rayk Aug 08 '12 at 14:32

1 Answers1

2

Unit of work is not data access pattern. It is representation of logical transaction = it is part of business logic and it belongs to your manager because the manager is orchestrating logical transaction from multiple services.

Your manager is a facade (or let's call it top level service) - it is still business logic and if the logical operation requires multiple low level services they should all run in single unit of work.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Ok, if the Unit of Work belongs to the business logic why is there the advice to implement the UnitOfWork within the Repository. Furthermore the Unit of work is inheriting from the DBContext and holds DBSets for the queries. Is maybe the Unit of work implementation wrong? – Rayk Aug 08 '12 at 14:36
  • 1
    Unit of work and repository are two completely different patterns with different purpose. In terms of EF, `DbContext` is unit of work and `DbSet` is repository. – Ladislav Mrnka Aug 08 '12 at 14:55
  • Ok so what is your advise? Use the DbContext in the Manager? maybe you have a example for me... – Rayk Aug 08 '12 at 14:59
  • Yes use unit of work in manager. If unit of work is directly EF context so be it. – Ladislav Mrnka Aug 08 '12 at 15:02
  • Ok Thanks! In case of my architecture the DBContext is part of my Reposoitory as I am using EF. So if I now make use of DBContext within my Manager that would mean I am breaking the architecture pattern. Where a Manager is just using one or more Services but not the Repositories... I got ur Point but isn't it a little bit dirty? :) – Rayk Aug 08 '12 at 15:10
  • But unit of work is not part of the repository. Unit of work handles atomic logical operation across multiple repositories. – Ladislav Mrnka Aug 08 '12 at 15:37