La parte del modello di MVC è una piattaforma interna

Il modello è proprio questo: un modello basato su oggetti del dominio aziendale. Il database è anche un modello del dominio aziendale, ma in una forma diversa, vale a dire tabelle e relazioni. Si completano a vicenda; ciò che manca, l'altro fornisce. Non è una piattaforma interiore; una piattaforma interna sovvertirebbe la tecnologia che sta imitando. Il modello non lo fa; dipende dalle caratteristiche di un database; non sostituisce queste funzionalità.

La mappatura relazionale dell'oggetto è una soluzione imperfetta al problema di mancata corrispondenza dell'impedenza. Ma i database relazionali e il loro linguaggio SQL sono una tecnologia matura e consolidata con molti vantaggi intrinseci . L'utilizzo di un ORM ti consente di avere il meglio di entrambi i mondi; è possibile memorizzare oggetti con una tecnologia matura e consolidata, ma utilizzare ancora SQL per risolvere i problemi di teoria degli insiemi.

Ulteriori letture
Il progetto "Vision", un ammonimento sull'effetto piattaforma interna
_{(Ecco come appare un realmente piattaforma interna. Puoi saltare il preambolo e iniziare a leggere nel sottotitolo "Presentazione di Vision" )}

Hai le cose nel modo sbagliato.

Il modello non è una replica scadente del database. Nessun programmatore si preoccupa della base di dati. Il data base esiste solo in modo che in una futura invocazione, possiamo facilmente ricostruire lo stesso stato dei nostri oggetti di business come prima. Le basi di dati sono strettamente un mezzo per un fine. Consentono un po 'di elaborazione e offrono alcuni trucchi per accelerare l'inefficienza causata dall'accesso alla memoria di massa, ma sono anche gli unici causa di questi problemi di inefficienza. Se potessimo cavarcela completamente senza basi di dati e invece continuassimo magicamente ad analizzare gli oggetti aziendali nella memoria di unicorni addomesticati, lo faremmo in un batter d'occhio.

Il modello non è così. Il modello supporta tutte le operazioni che possiamo eseguire nel nostro linguaggio di programmazione preferito, motivo per cui l'abbiamo scelto. Il modello è ciò che vorremmo programmare. È così fondamentale per il sistema che è molto importante non inquinarlo con preoccupazioni di altri livelli. Questo è il motivo per cui gli indici, le scansioni delle tabelle, ecc. Dovrebbero essere esclusi dal modello, ma anche perché le caselle combinate, le richieste HTTP ecc. Dovrebbero essere tenute fuori.

Non avere un modello significherebbe che lo stesso codice che si occupa di leggere e scrivere i widget si occupa anche degli INSERT SQL e dei parametri di connessione. Sarebbe molto brutto, perché pensare a due cose completamente diverse per tutto il tempo dimezza la tua efficienza come sviluppatore. Ecco perché è logico separare queste preoccupazioni e disporre di livelli che si occupano dell'interfaccia utente, della logica aziendale e dell'archiviazione dei dati. Porta a una maggiore quantità di codice, ma poiché ciascuna delle classi risultanti ha un focus più chiaro su cosa dovrebbe fare, l'efficienza generale aumenta.

Questo risultato è stato duramente conquistato da diverse generazioni di programmatori, e poiché non è ovvio, ogni nuova generazione deve essere convinta di nuovo che sarà meglio non tentare di fare tutto in una volta. Ma la maggior parte dei professionisti confermerà che in questo senso, avere classi più semplici è meglio, anche se si finisce con più code line in totale.

Solo nelle applicazioni meno complicate il modello potrebbe essere un duplicato del database e non necessariamente anche allora.

Fondamentalmente ciò presuppone una mappatura 1 a 1 tra i dati presentati al consumatore e la struttura della tabella del database (sia quella relazionale o altro) e in realtà è raramente il caso.

Se guardiamo MVC il modello è il modello per la vista - anche se questo rappresenta solo una singola riga da un singolo tavolo, le probabilità sono che ci saranno ricerche, campi che presentati al il consumatore ha un valore ma, come memorizzato nel database, ha un ID, il tuo modello potrebbe quindi contenere i valori di visualizzazione e anche i dati effettivi che sono persistenti.

Quindi entriamo in tutti i tipi di domande interessanti sulla convalida: cosa e come e dove.

Ora fai un altro passo - nota che ho detto "consumatore" - cosa succede se quel consumatore non è un utente finale che guarda uno schermo, che cosa è una singola pagina App che utilizza un'API. A questo punto dal punto di vista del client di fronte all'app non esiste un database - ma esiste un modello ...

Ciò che questo ci sta dando è una separazione logica dove guardiamo i modelli che sono appropriati al contesto in cui sono utilizzati - uno per l'interfaccia utente forse diverso per l'uso in business logic e quindi un modello di archiviazione che può be essere relazionale e coinvolgere più tavoli. Trattandoli separatamente e assicurandoci una comoda mappatura tra di loro, ci ritroviamo con una grande flessibilità nella nostra struttura generale (in cui il "sistema" può quindi distribuire abbastanza banalmente più applicazioni).

Ovviamente se tutto ciò che fai è CRUD diretto su tabelle di dati, allora la relazione tra modello di dati e modello di visualizzazione potrebbe essere abbastanza vicina, ma se si utilizza un database relazionale ci sarà sempre qualche mappatura.