4

I've been studying design patterns. I've learned about Repositories, Unit Of Work, Dependency Injection, MVC. I'm now learning about Service Layer pattern.

I'm trying to grasp the utility purpose of Unit of Work(if any) in a Service Layer.

From my understanding services provide encapsulation for specific model database access as a main goal. So if I provide an IService to a Controller that controller will only be able to access the specifics provided in a service, whilst if I provide an IUnitOfWork it will have access to all the Repositories available in it.

I mean it seams logical that the IService accesses the Repositories directly since it will encapsulate the database access and provide business logic at the same time.

So in an IService what's the goal of the Unit of Work? Is it worth having one?

  • 4
    As a rule of thumb - don't use patterns just for using patterns. If you have a problem that can be solved by unit of work, by all means, use it. If the problem could be better coded in some another way, don't force it into a Unit of Work structure just for the sakes of using UW. Patterns are a expression of a solution for a problem. They should never be a coding constraint. – T. Sar Mar 9 '17 at 11:46
  • 1
    You need to study your problem, then. The pattern you end up using should come as a consequence of your problem. You shouldn't look at them as a buffet of possible solutions - they aren't recipes. I can't stress this enough - patterns aren't tools to solve a problem, they are a way to catalogue code. – T. Sar Mar 9 '17 at 12:49
  • 2
    Another way to think about patterns is to relate them as animal taxonomies. You look at a lion and think "this is a feline", you look at a dog and think "this is a canine", you look at a platypus and think "this is a very weird creature". Patterns work the same - after you solve your problem, you look at your code and check what exactly it looks like. Sometimes it will look like a factory, sometimes it will look like a strategy pattern, sometimes it will just be a jumbled mess of code. – T. Sar Mar 9 '17 at 12:53
  • 2
    You don't start solving your problem by picking a pattern, however. Pattern's can't solve shit - they just give a name to similar ways to solve a problem. – T. Sar Mar 9 '17 at 12:54
  • 1
    That's the thing - problems don't require patterns, nor patterns solve problems. Patterns emerge once a solution from a problem is chosen. You don't go to a pet shop to buy a canine - you go to buy a dog, that happens to be a canine. See the difference? – T. Sar Mar 9 '17 at 13:14
1

These are two different patterns with completely different purpose:

  • The service layer is about application boundary and API (visibility & granularity of operations);
  • The unit of work is about transaction management and concurrency.

Of course the service layer could group operations that are exposed. For example save a PurchaseOrder together with its dependent LineItems in one operation, instead of an operation for saving PurchaseOrder and another for saving LineItems.

But this grouping / packaging would not solve the question of which item to update in the database if only one LineItem out of 10 in the PurchaseOrder got changed. It doesn't address either the concurrency issues when several users are trying to update the same PurchaseOrder at the same time. And that's the purpose of the unit of work.

The service layer isolates the domain logic from the outside front(e.g. presentation layer). The unit of work is used by the domain logic back-office.

  • So a service would contain both the repository(ies) and a unit of work where repos record data changes and UoW commits to database? – João Sequeira Mar 11 '17 at 10:59
  • @JoãoSequeira i wouldn't say "contain" but "packages" or "encapsulates", but yes,that's the idea: you'll need repositories & unit of work and the service will provide an API that hides all these details to the outside world. – Christophe Mar 11 '17 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.