5

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?

João Sequeira
  • 73
  • 1
  • 7
  • 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 09 '17 at 11:46
  • Thanks for the input. I'm not saying I'll use patterns just because. I'm trying to learn to when/if I need them. – João Sequeira Mar 09 '17 at 11:48
  • 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 09 '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 09 '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 09 '17 at 12:54
  • I'm not trying to solve a particular problem. I'm trying to understand logic in applying patterns should the problem presented require them. The question in itself is If UnitOfWork makes sense in a service pattern logic. I figure your answer (or at least your understanding) is that it depends on the problem presented. Yes? – João Sequeira Mar 09 '17 at 12:58
  • 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 09 '17 at 13:14
  • If you're not solving a particular problem, then you can't choose a pattern. Patterns are a consequence of the underlying problem and not a guide to a solution. They are not coding tools, they are _documentation_ tools. There is a huge movement nowadays trying to push patterns as silver bullets to solve everything, but don't be mistaken by it - they are useless without a good knowledge of what problem you're attacking. – T. Sar Mar 09 '17 at 13:16
  • I'm not very experienced but I'm experienced enough to understand that there are various ways to skin the monkey. But I'm studying patterns now and I'm just trying to understand some best practices entangled with them thus the question. If I don't study patterns there will be no 'emerge'... From studying patterns, specifically the Service Pattern, I got the feeling a unit of work doesn't make sense regardless the problem presented. That's the hole point of my question. – João Sequeira Mar 09 '17 at 13:22
  • Patterns are just names for common solutions. Nothing more. They won't help you develop better code if you don't understand your underlying problem. A Unit of Work is a bunch of things that need to be done together, like a group of SQL operations, happens together. A Service Layer Pattern is used to provide a set of operations to a client. – T. Sar Mar 09 '17 at 13:32
  • Neither of those have anything to do with repositories and neither of those have anything at all with each other. A Service could very well implement a few Unit of Work blocks inside of itself to access the database for the client, for example, or a Unit of Work can consume a service to ensure logging of its actions before going forward. – T. Sar Mar 09 '17 at 13:34
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/55059/discussion-between-joao-sequeira-and-tsar). – João Sequeira Mar 09 '17 at 13:35
  • Services don't need to be specific to databases nor units of work need to use repositories. Unless you _know_ what problem you're trying to solve, you can't pick a pattern or grasp how they interact. – T. Sar Mar 09 '17 at 13:35

1 Answers1

2

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.

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • 1
    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
  • 1
    @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