Bene, puoi vedere un buon esempio nel Spring Data Framework che si basa sul concetto di repository.
Si vedrà che gli archivi si occupano solo dell'archivio dati e raramente contengono qualsiasi logica aziendale (questa è riservata al livello di servizio). Quindi, ad esempio, dai uno sguardo al loro design, vedrai che hanno un CRUDRepository interfaccia che espone metodi per creare, distruggere e recuperare entità (tra le altre cose). C'è anche un PagingAndSortingRepository che aggiunge funzionalità extra esattamente per questo, risultati di ordinamento e paging, ecc. ecc.
Quindi, questo framework è forse un buon posto per studiare un buon progetto di repository.
Per quanto ne so, molti dei concetti implementati da Spring Data Framework provengono da un grande libro chiamato Dominio- Driven Design: Affrontare la complessità nel cuore del software , il libro ha un'intera sezione dedicata al design del repository.
Potresti prendere in considerazione una copia di questo.
Un piccolo estratto del libro spiega:
The REPOSITORY pattern is a simple conceptual framework to
encapsulate those solutions and bring back our model focus.
A REPOSITORY represents all objects of a certain type as a conceptual
set (usually emulated). It acts like a collection, except with more
elaborate querying capability. Objects of the appropriate type are
added and removed, and the machinery behind the REPOSITORY inserts
them or deletes them from the database. This definition gathers a
cohesive set of responsibilities for providing access to the roots of
AGGREGATES from early life cycle through the end.
Clients request objects from the REPOSITORY using query methods that
select objects based on criteria specified by the client, typically
the value of certain attributes. The REPOSITORY retrieves the
requested object, encapsulating the machinery of database queries and
metadata mapping. REPOSITORIES can implement a variety of queries that
select objects based on whatever criteria the client requires. They
can also return summary information, such as a count of how many
instances meet some criteria. They can even return summary
calculations, such as the total across all matching objects of some
numerical attribute.
A REPOSITORY lifts a huge burden from the client, which can now talk
to a simple, intention-revealing interface, and ask for what it needs
in terms of the model. To support all this requires a lot of complex
technical infrastructure, but the interface is simple and conceptually
connected to the domain model.
Therefore:
For each type of object that needs global access, create an object
that can provide the illusion of an in-memory collection of all
objects of that type. Set up access through a well-known global
interface.
Provide methods to add and remove objects, which will encapsulate the
actual insertion or removal of data in the data store. Provide methods
that select objects based on some criteria and return fully
instantiated objects or collections of objects whose attribute values
meet the criteria, thereby encapsulating the actual storage and query
technology. Provide REPOSITORIES only for AGGREGATE roots that
actually need direct access. Keep the client focused on the model,
delegating all object storage and access to the REPOSITORIES.