1

I am implementing the repository pattern in my application.

The repository will connect to an API to download orders from an external API. The API that I am connecting to has a separate endpoint to get the list of Orders and a separate endpoint to get the Items against that order.

Where should the marriage of OrderItems and Orders happen? Should the GetOrders() function in my repository get orders as well as items, returning it back to the service with both orders and items. Or should the service layer be responsible for running GetOrders() and GetOrderItems() and joining these together?

Hope that makes sense!

Improve this question

2 Answers 2

Reset to default
1

A principle from domain driven design might be useful here. Aggregate Roots.

If you Order object contains Items ie Order.Items then when you get an Order out of the OrderRepository it should have all the Items populated.

If it doesn't contain a list of Items then you can have a separate ItemsRepository with a method GetItemsForOrderId(string id)

The idea is that you may have a rule on the Order object which depends on the Items. say you can have an order with more than 10 items. Having the OrderReposity.SaveOrder() method deal with the Orders Items allows you to enforce that rule before persisting the Order.

My general rule is to have one repository per database. Since within a database the tables are likely to be joined in various ways and hence have these interconnected rules.

Improve this answer
0
0

Generally in N-Tier design you would have a tier of low level 'client' classes that deal with speaking to your backend API's. And a tier of 'delegate' (business logic) classes that deal with integration. Your Controller/View layer can then ask the appropriate 'delegate' for an aggregate list. If your layer is simply a protocol translater, proxying the api's then don't have a business logic layer. But why can't your client simply call the API's directly itself? What is the point of your layer? It seems to me that you should be performing the business logic.

Improve this answer
2
  • 1
    To be honest.... this answer has gone over my head! I am making a repository layer that will be responsible for getting data from the API, I'm just not sure if the repository should then put the data together or if that is the job of the service.
    – Lock
    May 3, 2017 at 11:31
  • If this is a .net specific question then I'm the wrong person. But I think the answer is yes. The job of your 'repository pattern' application is to simplify and buffer the back end from the client. Essentially this is about removing complexity for your client, so why not remove all the compexity. You have to be careful though. If the requirements of your client change, then you'll have to change your code. In other words, if this marrying of OrderItems and Orders could be done more than one way, then don't do it.
    – Richard
    May 3, 2017 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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