Modello di repository rispetto a oggetti aziendali "intelligenti"

Question

Vedo due principali "scuole di pensiero" quando si tratta di creare applicazioni su scala aziendale su .NET (Winforms, WPF, ASP.NET).

Alcuni usano il "modello di repository" che utilizza un repository che sa come recuperare, inserire, aggiornare ed eliminare oggetti. Questi oggetti sono piuttosto "stupidi" in quanto non contengono necessariamente un sacco di logica - ad es. sono più o meno oggetti per il trasferimento dei dati.

L'altro campo utilizza ciò che io chiamo oggetti di business "intelligenti" che sanno come caricarsi, e in genere hanno un metodo Save(), possibilmente Update() o addirittura Delete(). Qui non hai davvero bisogno di alcun repository - gli oggetti stessi sanno come caricare e salvare se stessi.

La grande domanda è: quale uso o preferisci? E perché?

Usi lo stesso approccio in tutte le tue app o hai qualche criterio particolare per scegliere un approccio rispetto all'altro? Se è così - quali sono questi criteri?

Non sto provando a iniziare una guerra di fuoco qui - solo cercando di scoprire cosa pensano tutti di questo e qual è la tua opinione, e perché usi uno (o entrambi) schemi sull'altro.

Grazie per qualsiasi input costruttivo!

Answer 1

Uso il modello di repository a causa del principio di responsabilità singola. Non voglio che ogni singolo oggetto debba sapere come salvare, aggiornare, cancellare se stesso, quando questo può essere gestito da un singolo repository generico

Answer 2

Il modello di repository non porta a oggetti stupidi. Se gli oggetti non hanno logica al di fuori del salvataggio/aggiornamento, probabilmente stai facendo troppo al di fuori dell'oggetto.

In teoria, non si dovrebbero mai usare le proprietà per ottenere dati dal proprio oggetto, calcolare cose e reinserire i dati nell'oggetto. Questa è una pausa di incapsulamento.

Quindi gli oggetti non dovrebbero essere anemici tranne se si utilizzano oggetti DTO semplici con operazioni CRUD.

Quindi separare i problemi di persistenza dalle preoccupazioni degli oggetti è un buon modo per avere una singola responsabilità.

Answer 3

Penso che l'effetto collaterale più importante dell'utilizzo del modello di deposito rispetto al modello ActiveRecord sia il test e l'estensibilità.

Senza che l'oggetto ActiveRecord contenga un repository stesso, come si isolerebbe il recupero dei dati nei casi di test? Non puoi davvero fingere o deriderlo facilmente.

Oltre a testare sarebbe anche molto più difficile scambiare le tecnologie di accesso ai dati, ad esempio da Linq-to-SQL a NHibernate o EntityFramework (anche se ciò non accade spesso).

Answer 4

Ecco due interessanti articoli mi sono imbattuto

Repository-is-the-new-singleton

The DAL should go all the way to UI

Answer 5

E 'davvero dipende dalle esigenze dell'applicazione, ma quando si tratta di un modello di business complesso, preferisco ActiveRecord.Posso incapsulare (e testare) la logica aziendale in un unico posto.

La maggior parte degli ORM (EF, nHibernate, ecc.) Funge da repository. Molte persone considerano un livello in cima a un ORM che incapsula tutte le interazioni di dati come un repository, che ritengo non corretto. Secondo Martin Fowler, un repository incapsula l'accesso ai dati come una raccolta. Pertanto, disporre di metodi individuali per il recupero/la mutazione di dati potrebbe utilizzare un Data Mapper o un oggetto di accesso ai dati.

Utilizzando ActiveRecord, mi piace avere una classe di base "Entity". Di solito uso un ORM (repository) con questa classe base, quindi tutte le mie entità hanno metodi GetById, AsQueryable, Save ed Delete.

Se utilizzo una architettura orientata ai servizi, utilizzerò un repository (quello che maschera l'accesso diretto ai dati o un ORM) e lo chiamiamo direttamente nei miei servizi.