Cosa dovrebbe fare davvero un repository?

11

Ho sentito molto del pattern di repository, ma non ho capito cosa dovrebbe fare davvero un repository. Quando dico "cosa dovrebbe fare davvero un repository" sono principalmente preoccupato dei metodi che dovrebbe fornire. Ad esempio, se un repository fornisce realmente metodi CRUD, o dovrebbe fornire un tipo diverso di metodo?

Voglio dire, se i repository contenessero logiche di business o dovessero semplicemente contenere la logica per comunicare con l'archivio dati e gestire le entità da salvare o caricare?

Ho anche sentito che i repository sono unità di persistenza per gli aggregati. Ma come è? Non riesco a capire come funziona in pratica. Ho pensato che dovremmo avere solo un'interfaccia IRepository che contiene i metodi CRUD, e quindi per qualsiasi entità l'implementazione conterrebbe semplicemente la logica per salvare e recuperare tale tipo dall'archivio dati.

    
posta user1620696 31.03.2014 - 16:38
fonte

2 risposte

11

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.

    
risposta data 31.03.2014 - 17:00
fonte
2

Non dovrebbe fornire né un'interfaccia CRUD diritta né una logica aziendale. Media tra business logic e database. L'interfaccia dovrebbe essere in termini di business logic ma non eseguire la logica di business stessa, più come una logica di business primitiva. Ad esempio, hai intenzione di costruire un sistema di posta elettronica, hai utenti e messaggi. Il tuo repository fornirebbe operazioni CRUD di base per utenti e messaggi ma fornirà anche visualizzazioni filtrate di messaggi come GetUsersNewMessages (utente) o GetSearchedMessages (utente, searchTerms).

L'idea è che il Repository nasconda il modo in cui lo storage è implementato e fornisce un'interfaccia pulita che consente un accesso flessibile e veloce ai dati. Mantenere le operazioni in termini di alto livello di ciò che dovrebbe succedere piuttosto che in termini di modalità di maggiore flessibilità per implementarle in qualsiasi modo è il migliore per il backing store sottostante.

    
risposta data 31.03.2014 - 17:26
fonte

Leggi altre domande sui tag