1

during the last days I've read some tutorials and topics about the Repository Pattern and the Unit of Work.

I was able to understand the UoW idea, and it's a very good one, my problem now is how to replicate something like this to the Service layer (which would be my BLL). I have a thought stuck in my head and I hope I can be clear enough about it, maybe I haven't understood the concept properly.

Let's imagine the following:

  • I have a ClientService and a OrderService.

  • In my Client service I have a method called RemoveClient

  • In my Order service I have a method called RemoveOrder

On one hand, when I call my RemoveClient method, I'll check a ton of stuff before allowing it to be deleted and in cases of deletion I'll delete all of his orders too. On the other hand, when I call my RemoveOrder I'll have other stuff to check before deleting it too (different stuff from the RemoveClient method), all of these deleting rules are contained in my Service Layer.

In most of the examples I've seen lately, a Service always calls the UoW of the repository, but since there's no business logic on my repository it doesn't make sense to me. When I'm deleting my Client isn't it better to always call the OrderService from my ClientService instead of calling the ClientRepository and OrderRepository directly from my ClientService, this way making sure that all the validations are being done for both elements.

If it is better to always call the Services (to keep the business logic "flowing") how could I keep the Services in the same context (like UoW does for the Repository).

I hope I was clear enougth. Thank you.

Rafael Merlin
  • 2,517
  • 1
  • 25
  • 31
  • 3
    My understanding is the business logic stays in the service layer, but the code that actually changes the database goes into the Repository. So all of checks stay in the service layer, but if you need to add, update, or remove items from the database, you do that at the repository level. The service layer calls the repository to do those simple things. – Tony Vitabile Apr 11 '14 at 14:31
  • @TonyVitabile so the best approach would be always calling the Service, correct? Each service can see only it's own repository, or maybe I'm just confused? How can I accomplish this in the same context? Thank you. – Rafael Merlin Apr 11 '14 at 15:44
  • 1
    Yes, each Service has its own Repository which performs low level operations for it. The Service determines which Repository operations to call based on business logic. In fact, its best if the code that calls the Service only knows of the Service and doesn't know of the Repository at all. – Tony Vitabile Apr 11 '14 at 17:09
  • @TonyVitabile sorry for bothering you so much, but can you clarify something for me? If I have a Service Layer and a Repository Layer, the UoW would handle the Repositories instead of the Services, correct? How could I for example keep the same context in a MultiServices call, example: Service A (which owns Repository A) is going to call Service B (which owns Repository B) instead of calling directly the UoW for repository B by itself. How can I keep context here while still having the option of calling the Service B without sending the context from another part of the system? Thanks. – Rafael Merlin Apr 14 '14 at 19:45
  • 1
    You probably have an instance of Service A & one of Service B in your program, call those `ServiceA` & `ServiceB`. If Service A needs to call Service B, you pass `ServiceB` to the method in `ServiceA` that needs it as a parameter. That method, therefore, can't be called without passing an instance of Service B. On the other hand, if Service B is a static class, you just call the method you need to call in the method of Service A. – Tony Vitabile Apr 15 '14 at 12:31

1 Answers1

0

First of all have a quick read on this question How to use the repository pattern correctly?. Then read the most voted answer. Now, the juicy part lies in the comments starting from this one.

Long story short, if your business domain complexity need a rich domain model then you should delve into the world of DDD where Aggregate roots will simplify the interactions and relationships between Entity and Value objects. This will make the use of repositories more distinct (or even obsolete if you approach persistence from CQS perspective) as their existence will be determined by your aggregate roots. Your service layer then will be more lean in term of business logic load or even non-existent if your domain design fulfills all the business requirements needed.

Lastly, having a rich domain model governed by DDD disciplines allows you to enforce cascading referential integrity especially if you decide to adopt an ORM to your persistence strategy.

Community
  • 1
  • 1
Sakis
  • 141
  • 6