In un sistema MVC, dove dovrebbe trovarsi il codice di persistenza del database?

21

Ho visto più configurazioni per informazioni persistenti nel database. In genere, tre tipi di design sembrano comuni nel mio angolo di mondo:

Il controller gestisce la persistenza
Il modello gestisce la persistenza
La libreria di terze parti gestisce la persistenza, in genere richiede una sorta di annotazioni sul modello.

Mi chiedo quale configurazione (se presente) è, concettualmente, la più semplice da usare / la più compatibile con un'architettura MVC?

(Se non è quello che ho elencato, si prega di fornire una rapida struttura / panoramica come parte della risposta)

mvc

— blueberryfields
fonte

13

La tua seconda e terza opzione sono identiche. La M in MVC non è il modello di dati, ma piuttosto il modello di dominio. Ciò include la persistenza, eseguita direttamente o tramite un ORM, ed entrambi sono perfettamente corretti.

Il controller dovrebbe gestire il flusso del sito e passare le cose al dominio (a volte tramite un livello di servizio) per essere gestito, quindi persistere da lì è sbagliato - o almeno semanticamente scomodo.

— pdr
fonte

2

Non sono d'accordo in una certa misura. L'utilizzo concreto della persistenza è la logica dell'applicazione e quindi appartiene a un livello applicazione e non al livello dominio. Il livello di dominio (contenente il modello di dominio) dovrebbe essere ignaro della persistenza per il programma aziendale occasionale. Il controller è un orchestratore . Può orchestrare servizi (dati), l'interfaccia utente e il modello di dominio.

— Falcon,

1

@Falcon: Mentre il controller dovrebbe controllare quando i dati vengono caricati e persistenti nel database, è perfettamente corretto fargli dire al modello di farlo. L'uso di un ORM (standard o roll-your-own) di solito significa dire al modello di caricare / salvare che quindi delega all'ORM. Un altro modo potrebbe essere quello di fare in modo che il controller indichi a un ORM di caricare / salvare qualcosa passando una classe di modello da caricare (con criteri di selezione) o un'istanza di modello da salvare. In entrambi i casi, l'effettivo caricamento / salvataggio sarà legato in modo tempestivo al modello.

— Marjan Venema,

@Marjan Venema: Sì, sono d'accordo, ma la domanda è dove dovrebbe vivere quel codice. Mi sforzo di mantenere il modello il più possibile ignorante della persistenza e modellare solo le entità del dominio con i loro comportamenti e interazioni. Qualsiasi altra cosa vivrà nei livelli di applicazione (in quanto è un'applicazione del mio modello). La mappatura delle informazioni / accesso ai dati è completamente disaccoppiata dal modello di dominio e può anche occuparsi del controllo delle versioni (upgrade / downgrade). L'applicazione dell'accesso ai dati vive anche nei livelli dell'applicazione (che contengono servizi, archivi ecc.)

— Falcon,

@Falcon: Sì, è un buon modo per farlo ed è come l'ho fatto in passato usando classi di mappatura separate. Tuttavia, con l'avvento dell'RTTI esteso (Delphi) e della riflessione (.Net e altri), non ho scrupoli nell'usarli insieme all'annotazione degli attributi del Business Object Model per far funzionare tutto e usare solo sovraccarichi di, hook di codice in e / o classi di inizializzazione specificamente codificate per gestire il controllo delle versioni del database.

— Marjan Venema,

5

Realisticamente, MVC è principalmente un modello di implementazione dell'interfaccia utente, quindi la domanda è piuttosto controversa. Tuttavia, ci sono davvero solo due opzioni per immagini grandi. Il controller in genere invia richieste di caricamento o salvataggio di entità nel modello utilizzando 1) un livello di servizio di qualche tipo o 2) il modello di record attivo.

Il livello di servizio può assumere una serie di forme, sebbene la mia preferenza personale sia quella di lavorare con un'astrazione del repository per le entità radice aggregate, le cui implementazioni concrete funzioneranno con una sorta di ORM, o un DAO leggero o un API per alcuni negozi non relazionali se questo ha senso per l'applicazione.

Il modello Record attivo significa che il tuo modello ha la responsabilità della persistenza, sebbene di solito significhi che una classe base di qualche tipo gestisce i mapping al tuo negozio, quindi il tuo modello non è realmente così direttamente coinvolto.

Fondamentalmente, il controller invia richieste di persistenza di oggetti, sia che si tratti di una chiamata al repository, dell'implementazione di UnitOfWork o del metodo Save sulle entità. Se si utilizzano repository, gli oggetti modello sono ignoranti per persistenza.

— JasonTrue
fonte

3

In un sistema MVC (model-view-controller), il modello contiene i dati. Quindi credo che dovrebbe esserci la persistenza del database.

— Nettogrof
fonte

2

La maggior parte dei campioni MVC di alto livello che ho visto hanno un infrastructurelivello separato che ha l' effettivo codice di implementazione del database (cioè le chiamate specifiche a NHibernate, o EF o Linq o qualunque sia il tuo livello dati), mentre il livello "modello" (spesso anche il livello "Dominio") ha le interfacce che definiscono i servizi dati.

— Wayne Molina
fonte

0

La pratica standard in MVC è quella di includere la struttura dei dati e la persistenza nel livello M (odel).

Il livello del modello non include solo le classi (POCO ecc.) Che verranno utilizzate nella propria applicazione. Includono i repository per quelle classi.

Un esempio potrebbe essere un repository in cui sono presenti gruppi di istanze di classi di dati, ovvero:

Clients repository

AllClients()
RecentClients()
ClientByID(int id)

Sarai in grado di organizzare meglio il dominio del tuo modello e avrai anche accesso ai tuoi dati in molti modi, ma il livello dati / modello sarà comunque compatto e robusto

— Mihalis Bagos
fonte