1

I am trying to understand what is the proper approach when the objects generated from a Repository have a reference to objects which are responsible for another Repository.

Let's say I have terminals which can have a list of possible quantities assigned and each quantity has a type. In this case I have 3 repositories TerminalsRepository, QuantitiesRepository, and QuantityTypeRepositories.

How should I populate the quantities information for the terminals and the type information for the quantities? Should the repositories use internally the other repositories or is there a better way to achieve that (for example a service method is retrieving the terminals and then populating the needed data)?

  • 7
    Since terminals, quantities and quantity types are so closely linked, I’d question why they all exist in their own repositories, than than coexisting in one repository. – David Arno Jun 9 at 5:45
  • 2
    Why exactly do you need to populate the terminals with the the type and quantity information? For what purpose? Is it required by some business function, or is it perhaps for displaying the data? – Andy Jun 9 at 7:12
  • 1
    @djvuk, it is usually the best to introduce a completely different data model for display purposes, a model which can be loaded very fast, e.g. using a fine-grained SQL query. For the business part of your model, whether you should load everything at once or not depends on your architecture, the concept of transaction boundaries, business rules, and also e.g. whether quantities are entities on their own or are merely a part of a bigger concept, the terminals. As of now, answering your question is pretty difficult, as it's too broad. – Andy Jun 9 at 7:50
  • 1
    Note that the Repository pattern is meant to abstract the domain from the mapping model (usually an ORM). but it does not say (nowhere) there should be 1 repository per mapping. What it says is that such an abstraction hides the complexity of the mapping model. To me it means that 1 repository can manage all your three entities as needed so the domain can remain agnostic to how and where the info is stored and retrieved. In this specific case, IMO, makes sense because of what @DavidArno has commented – Laiv Jun 11 at 15:08
  • 1
    I'd echo the other comments that these should be in the same repository. If you put related things in different repositories, basic things like referential integrity and transnational consistency become very difficult and you often have to push that logic to a higher level of abstraction, which can be detrimental to separation of concerns. – John Wu Jul 10 at 17:52
1

You seem to limit the purpose of the Repository pattern. In small and/or simple projects, you often have a 1-to-1 mapping of repositories and DB tables/entities, and repositories are useful too in this simple way of working.

But the point of a repository is to enable you to abstract away how you persist your domain objects. They could be all in RAM, in a file, on an other computer, etc. The point being that your domain objects don't always represent or even have a direct DB equivalent, and this is the purpose of your repository : to execute a JOIN on how many tables are needed to give you back your completed object, or to

In your case, as some others have said in the comments, I'd be tempted to have only the TerminalRepository, and have your Terminal object hold everything you told us. The concept here being that your Terminal is an aggregate root, since the Quantity and QunatityType objects have no meaning by themselves (as I understand), you don't need a repository to persist or fetch them independently.

| improve this answer | |
-1

Don't have objects which span repositories.

Just put the id of the other object on the first so that you can get the linked object from the other repo if needed.

As a rule of thumb have one repo per database one table per object. So objects which are strongly linked (tables with FK relationships) are in the same repo.

Where you have something outside your db, say a large file, include a fileId in the db and on your object and do the same for the 'root agregates' from other DBs

| improve this answer | |
  • One Repo per DB could be very hard to conceal for many of the projects out there. But the idea is interesting. It could be doable tho, to implement repositories per schemas/db-users where each schema/db-user has access to a limited set of resources and the access to foreign resources is limited by grants or privileges. – Laiv Jun 11 at 12:47
  • Yeah schema is another good split if you have big dbs where you use that abstraction layer – Ewan Jun 11 at 12:50
  • 1
    You seem to conflate "repository" with "context/unit of work". A repository is not a database-spanning concept, its specifically limited to an entity or aggregate, i.e. a data object. Quoting Martin Fowler: "Conceptually, a repository encapsulates a set of objects stored in the database and operations that can be performed on them" (link) – Flater Jul 10 at 10:25
  • I'm not sure how you get that from my answer – Ewan Jul 11 at 15:20

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.