How do read-only database views fit into the repository pattern?

Question

Example: Your database has a SQL view named \"CustomerOrdersOnHold\". This view returns a filtered mix of specific customer and order data fields. You need to fetch data fro

Answer 1

I think that it is fine to have a separate repository like "CustomerOrdersOnHoldRepository". The interface of the repository will reflect the fact that the objects are readonly (by not defining Save/Add/MakePersistent method).

From How to write a repository:

... But there is another strategy that I quite like: multiple Repositories. In our ordering example there is no reason we can have two Repositories: AllOrders and SurchargedOrders. AllOrders represent a list containing every single order in the system, SurchargedOrders represents a subset of it.

I would not call returned object an Aggrgate Root. Aggregates are for consistency, data exchange and life cycles. Your objects don't have any of these. It seems that they also can not be classified as Value Objects ('characteristic or attribute'). They are just standalone classes.

Answer 2

Your read-only data would be considered Value Objects in the DDD world.

I typically place access methods for value objects in existing repositories until such time that it makes sense to create a separate repository. It's similar to a method that might return a static list of states to be used on an address form:

IAddressRepository
{
  Address GetAddress(string addressID);

  List<string> GetStates(string country);
}

Answer 3

I would prefer separating the read repository, preferably even change its name to Finder or Reader, the repository is meant for Domain usage not for querying read-only data, you can refer to this article and this which explains the usage of Finder separated form repository.

I would recommend also the separating of read model from write model architecture CQRS and there

This architecture allows you to separate the read model from write model even in terms of data storage and the use of event sourcing.

For a middle solution you can utilize some CQRS concepts without the complexity of separating database by just separating repository from finders, read this post

for a sample of this type of solution (use the same database but separating finders form repositories) check this sample