I'm working on an API and I always seem to run into this thought debate. When designing the code structure that interacts with the database (repositories, data providers ect..) how do I structure the repositories based on hierarchical relations?

For example I have an app with Items and those items have images. Do I make one repository with CRUD operations for both the images and the items or do I make two?

I usually ask myself "well how am I going to be modifying the data?" and it usually makes sense to do one repository for business reasons. I'm always going to add an image in relation to an item. However if I want to have something like an administrator UI backing it, anything goes, as all of the sudden those tables are now almost modifiable as if they are their own entities. The relationship still holds true but I would want to do something like Get All Images or remove this image because it's offensive.

The goal is to try and make the code structure make sense and be the most useable.

  • Why would you store more than the absolute minimum necessary to find the image (which presumably will have its own attributes stored in the image file)? – Adam Zuckerman May 10 '16 at 5:05
  • A repository is not forced to be a db repo. Any DAO is an interface to allow access to the data. You can store img meta data on db and to have a repo that does CRUD over filesystem. It does make sene to me, overall if I don't want to store the img on db. It also can be a Helper or a Manager instead of a repo. Depends on where you want to locate the component (Facade) – Laiv May 10 '16 at 6:18
  • I usually don't introduce repository returning an object from BL layer per table until I need only data from the specific table. If I have interconnected tables and I am always querying only in one way, where to obtain data from table A I will always need data from table B, I just put it in one repository. Once I introduce a specific repository for table B, I inject it to table A repository and use that one for querying, but not before I need contents of table B as standalone objects. – Andy May 10 '16 at 9:47
  • @Ashtonian in the book Domain Driven Design, Eric Evans has roughly the same thought process about related business objects and that leads him to introducing the Aggregate pattern. You might want to read up on it. – guillaume31 May 10 '16 at 11:47

Your Answer

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

Browse other questions tagged or ask your own question.