Metodi di database sulle entità

Question

Metodi di database sulle entità

#1 da (4 voti)

1

Sto avviando un nuovo progetto e c'è un dibattito interno sul giusto approccio alla scrittura di oggetti in un database.

Le operazioni CRUD richiedono 3 parametri: Gestore DB, Nome DB, Nome raccolta.

Tutti gli oggetti sono derivati da un oggetto BaseEntity (che ha l'Id standard, Tempo di creazione, Tempo di aggiornamento, ecc.)

Il primo approccio consiste nel mettere le operazioni CRUD nella classe BaseEntity. Quindi puoi fare:

var obj = new MyObject() { ... }
obj.Insert(DB, DBName, CollectionName);

Il secondo approccio è creare una classe che controlli le operazioni CRUD:

var collection = new Collection(DB, DBName, CollectionName);
var obj = new MyObject() { ... };
collection.Insert(obj);

Ho il mio metodo preferito (non dire quale) ma quali sono alcuni dei possibili vantaggi / svantaggi di ciascuna soluzione?

La lingua in uso è C # ma non penso che importi davvero.

design-patterns

posta Shaun 14.10.2018 - 22:02

fonte

1 risposta

Leggi altre domande sui tag design-patterns

Pattern modulo in C con threading - dove controllare i thread? Quali sono i vantaggi di un ciclo foreach rispetto a un ciclo for body-less

score 4 · Accepted Answer

Supponendo che MyObject sia una classe di modello che rappresenta qualche concetto nel tuo dominio, allora separazione delle preoccupazioni suggerisce che la logica del database debba essere gestita separatamente - portando a un oggetto raccolta o archivio separato. Anche questa soluzione sembra molto più comoda perché ora non devo passare oggetti DB / DbName / CollectionName separati.

Vedi anche:

Principio di responsabilità singola,
Coesione (se lo stesso codice è responsabile per cose diverse questo non è molto coeso)
Accoppiamento (se la classe del modello è responsabile della logica del database, è accoppiata all'interfaccia del database)

Tuttavia entrambe le soluzioni sono probabilmente soddisfacenti. Più importante della scelta della soluzione leggermente migliore è quella di essere coerenti all'interno del codice base e dell'ecosistema. Molti, molti progetti di successo utilizzano un approccio di stile ActiveRecord in cui il modello di dominio è responsabile della propria persistenza e anche perfettamente soddisfacente .

In particolare, ci sono spesso preoccupazioni trasversali come la serializzazione o persistenza che sono necessarie per tutti i tuoi oggetti. La "singola responsabilità" per questa preoccupazione può essere argomentata in entrambi i modi: se l'oggetto è responsabile della propria persistenza, tutte le funzionalità correlate a quell'oggetto sono raggruppate in una sola classe coesiva. In alternativa: se un oggetto repository separato è responsabile della persistenza delle classi, tutta la logica di persistenza è raggruppata in una sola classe coesiva.

La scelta tra queste alternative è spesso, ma non sempre, arbitraria. Le cose che dovrebbero cambiare insieme dovrebbero essere raggruppate insieme. Se è probabile che si aggiungano nuove classi o si cambi il modo in cui una singola classe viene mantenuta, mantenere la logica di persistenza nella classe sembra ragionevole. Al contrario, se è più probabile che si modifichi il meccanismo di persistenza (ad esempio, il passaggio a un database completamente diverso), l'utilizzo del modello di repository sembra più sensato. Ma quando tutte queste classi fanno parte dello stesso progetto / soluzione, sono effettivamente raggruppate in entrambi i modi: una visualizzazione a grana troppo fine non è sempre utile.