Come dovrei architettare il mio modello e gli oggetti del livello di accesso ai dati nel mio sito web?

Question

Come dovrei architettare il mio modello e gli oggetti del livello di accesso ai dati nel mio sito web?

#1 da (4 voti)

6

Mi è stato assegnato il compito di progettare il livello dati per un sito Web al lavoro e sono molto interessato all'architettura del codice per la massima flessibilità, manutenibilità e leggibilità.

In genere sono consapevole del valore nel separare completamente i miei modelli reali dal livello di accesso ai dati, in modo che i modelli siano completamente ingenui quando si tratta di accesso ai dati. E in questo caso è particolarmente utile farlo poiché i Modelli possono essere creati dal Database o possono essere creati da un servizio Web Soap.

Quindi mi sembra logico avere Factories nel mio livello di accesso ai dati che creano oggetti Model. Quindi ecco quello che ho finora (nel mio pseudocodice inventato):

class DataAccess.ProductsFromXml extends DataAccess.ProductFactory {}
class DataAccess.ProductsFromDatabase extends DataAccess.ProductFactory {}

Questi vengono quindi utilizzati nel controller in modo simile al seguente:

var xmlProductCreator = DataAccess.ProductsFromXml(xmlDataProvider);
var databaseProductCreator = DataAccess.ProductsFromXml(xmlDataProvider);

// Returns array of Product model objects
var XmlProducts = databaseProductCreator.Products();
// Returns array of Product model objects
var DbProducts = xmlProductCreator.Products();

Quindi la mia domanda è: questa è una buona struttura per il mio livello di accesso ai dati? È una buona idea usare una fabbrica per costruire gli oggetti del mio modello dai dati? Pensi che abbia frainteso qualcosa? E ci sono degli schemi generali su cui dovrei leggere per come scrivere i miei oggetti di accesso ai dati per creare gli oggetti del mio modello?

database data-structures mvc model

posta Robin Winslow 17.10.2012 - 22:33

fonte

1 risposta

Leggi altre domande sui tag database data-structures mvc model

Macro Lisp: un approccio pratico Ambiente isolato per stack di software

score 4 · Accepted Answer

I am generally acutely aware of the value in completely separating out my actual Models from the Data Access layer, so that the Models are completely naive when it comes to Data Access.

Si parla di ignoranza della persistenza. Un altro concetto che potresti voler introdurre nel tuo livello di accesso ai dati è il repository . La funzione centrale di un repository è incapsulare l'accesso ai dati.

In un'architettura MVC, il controllore farebbe riferimento al repository per ottenere l'accesso ai dati. I dettagli specifici della formattazione dei dati dovrebbero essere nascosti dal repository, in questo modo il tuo controller rimane anche ignorante sulla persistenza. Tuttavia, i repository vengono talvolta applicati erroneamente quando viene tentata un'astrazione eccessiva. Non cercare di rendere i repository eccessivamente generici e in grado di gestire qualsiasi tipo di scenario di accesso ai dati perché molto probabilmente fallirai e finirai con molte astrazioni inutili che complicano molto di più di quanto possano semplificare.