Il presente articolo è stato tradotto automaticamente.
Gli oggetti e l'arte della modellazione dei dati
.jpg "Dino Esposito")
Molte delle applicazioni odierne sono basate su un modello di data singola, in genere inserito in un archivio dati tramite uno strumento di mapping relazionale a oggetti (ORM). Ma a volte, ovvero per vari motivi diversi, potrebbe essere necessario una maggiore flessibilità, che richiede più modelli. In questo articolo illustrerò alcune strategie che è possibile utilizzare per gestire queste situazioni e sviluppare applicazioni più affidabili e a più livelli.
Utilizzo di modelli diversi chiaramente rende l'intera applicazione più complessa, ma è una sorta di complessità necessari, positivo che rende più semplice da gestire l'intero progetto. Comprendere quando un modello di dati è sufficiente non è possibile adattare tutti i casi di utilizzo è la sfida per gli architetti.
Diverse parti di un'applicazione software potrebbero essere il proprio modello di dati. Il modo in cui è possibile rappresentare i dati a livello di interfaccia utente è diverso da quella in cui si organizzano i dati nel livello intermedio e può essere anche diverso dal modo in cui i dati vengono mantenuti fisicamente in un tipo di archivio dati.
Tuttavia, per molti anni, gli sviluppatori utilizzavano un solo modello di dati, indipendentemente dalla parte dell'applicazione in questione. Molti di noi siano cresciute con database relazionali e le tecniche di modellazione correlati. È stato naturale dedicare un notevole impegno nel redigere un modello basato su relazioni e le regole di normalizzazione. Tutti i dati memorizzati in un database relazionale è stata quindi estratti e spostati utilizzando le strutture di memoria simili a un database in memoria. Set di record è il nome di questo modello di dati generici (vedere bit.ly/nQnyaf); ADO.NET DataSet è un'implementazione ottima di esso.
L'approccio basato su tabella è stata progressivamente mettendo da parte dalla complessità sempre crescente di applicazioni. Strumenti ORM apparsa per due motivi pragmatico. In primo luogo, utilizzo degli oggetti è più semplice rispetto all'utilizzo di super-arrays generico di dati, ad esempio un oggetto recordset. Il secondo motivo è la produttività. L'obiettivo di ORM viene tenuto un modello a oggetti e associandola a uno schema relazionale. Utilizzando un ORM, essenzialmente apportate al modello a oggetti simile al database reale per gli occhi dell'applicazione.
Come si può progettare questo modello? E dovrebbe utilizzi un solo modello per ogni applicazione? Andiamo a scoprirlo.
Il recente supporto release dell'Entity Framework (EF) 4.1 incluse nella programmazione "Codice First", che, come il nome suggerisce, consente a Microsoft.NET Framework possono adottare un approccio del primo codice alla modellazione dei dati. In pratica, ciò significa che inizia scrivendo le classi normale vecchio CLR oggetto (POCO) che il dominio dell'applicazione del modello. Il secondo passaggio è costituito da queste classi il mapping a un tipo di archivio permanente e con lo strumento ORM (EF) occuparsi dei dettagli di persistenza. La metodologia ORM espone un linguaggio di query (LINQ to Entities), la semantica transazionale (gli oggetti xxxContext di EF) e crea una base, leggere, aggiornare ed eliminare i piani di API che supporta la concorrenza, lazy durante il caricamento e fetch (CRUD).
Pertanto, è necessario che il modello e si sa come venga conservato e ricercare informazioni da esso. Si tratta di un modello che è possibile utilizzare ovunque nell'applicazione? Più specificamente, si tratta di un modello che possono essere inseriti in modo efficiente al livello di presentazione? Questo è un punto dolente realmente dove theory and practice differiscono sostanzialmente, il contesto è king e incertezza (quando non realmente confusione) privilegiata. È possibile offrire un esempio concreto associato all'applicazione ASP più diffusi.Tecnologia NET MVC. L'unico motivo per cui che si sta utilizzando ASP.NET MVC invece di pronuncia, Silverlight, è che ASP.NET MVC è il modello word nel nome (M in MVC) — e mi hanno posto troppe volte nelle classi e le conferenze relative alla posizione esatta del "modello" in una pagina ASP.Applicazione di NET MVC.
Oggi, anche dopo tre versioni, troppi esercitazioni su ASP.NET MVC insistere sull'utilizzo di un solo modello per le query, gli aggiornamenti e la presentazione. Molte esercitazioni anche mantenere la definizione del modello all'interno del progetto principale. Esso lavori, di così in cui il problema? Il problema non è la soluzione, che funziona, è efficace ed è qualcosa ho spesso già utilizzato da solo e si prevede di continuare a utilizzare. È effettivamente una serie di reali ma semplice e relativamente breve applicazioni (non solo le dimostrazioni ed esercitazioni), che possono essere sviluppate con modelli semplici. È il problema dell'utilizzo di un solo modello con il messaggio viene trasmesso per i consumer primari delle esercitazioni: gli sviluppatori che desiderano per apprendere una tecnologia. Presenza di un solo modello in un'unica posizione suggerita è la preferita (non consigliato) a eseguire le operazioni. È, invece, è sufficiente un caso speciale, ovvero uno scenario molto semplice e favorevole. Se lo scenario reale in che sarà effettivamente lavorate corrispondano a quelli, si è più di fine. In caso contrario, si è bloccato e pronta a crescere il primo "big ballo fango" più grande e più grande.
Iniziamo utilizzando nomi leggermente diversi. Chiameremo il modello di dati che persistono al modello di dominio e richiamare i dati è gestire nella visualizzazione del modello di visualizzazione. È importante menzionare che tale modello di dominio non è esattamente un termine neutro nel software, quanto si riferisce a un modello a oggetti progettato in base a un numero di regole aggiuntive. Nell'ambito del presente articolo, non si utilizza il significato che deriva dalla metodologia di progettazione basata (ggg). Per me, in questo caso, il modello di dominio è semplicemente il modello a oggetti è mantenere, ovveroentity model potrebbe essere l'equivalente di un altro e più chiaro, ovvero a termine.
È possibile utilizzare le classi nel modello di entità nel back-end dell'applicazione. è possibile utilizzare le classi nel modello di visualizzazione del livello di presentazione. Si noti, tuttavia, che in ASP.NET MVC, il livello di presentazione è il controller. Il controller dovrebbe ricevere i dati pronti per l'interfaccia utente. I componenti di livello intermedio ricevono e restituiscono gli oggetti del modello di visualizzazione e utilizzano internamente gli oggetti di entità. Figura 1 Mostra web delle dipendenze in un progetto tipico a più livelli.
.png)
Figura 1 le connessioni tra i livelli
La presentazione (vale a dire la classe code-behind o controller) fa riferimento la logica dell'applicazione, vale a dire un componente che implementa i casi di utilizzo dell'applicazione. La logica dell'applicazione tecnicamente appartiene al livello aziendale o a livelli e in casi molto semplici potrebbe essere unita con la presentazione. Ciò avviene in alcune esercitazioni sono troppo semplice realtà sentirsi la necessità di isolare la logica dell'applicazione nel suo piano oppure progettazione inadeguata e suddivisione logica dell'applicazione tra la presentazione e il livello di accesso ai dati (DAL).
L'assembly di logica dell'applicazione implementa il modello del livello di servizio e separa due livelli di interfacciamento: presentazione e dati. La logica dell'applicazione fa riferimento al modello di entità (classi di dominio) e Data Access. Coordina la logica dell'applicazione DAL, le classi di dominio e servizi di far valere il comportamento previsto. La logica dell'applicazione comunica con il livello di presentazione tramite gli oggetti del modello di visualizzazione e comunica con data DAL attraverso gli oggetti del dominio. DAL, fa riferimento a sua volta, il modello e l'assembly ORM.
Esaminiamo questa architettura, supponendo che EF come la metodologia ORM. Il fattore non è semplicemente un ORM, ma come suggerisce il nome, esegue automaticamente le operazioni tipiche degli ORM, oltre a offrire un framework per la creazione di un modello. Idea interessante, ma non dovrebbe essere dimenticato che ci stiamo estendano due livelli distinti, ovvero business e Data Access. Le classi sono attività; il motore di persistenza è data DAL. EF, il motore di persistenza (assembly ORM) è system.data.entity e le relative dipendenze, inclusa la classe ObjectContext. In altre parole, se non si utilizzano le classi POCO e il primo codice, sarà probabilmente finisce con un modello di dominio che ha una dipendenza di ORM. Un modello di dominio deve utilizzare POCO, vale a dire tra l'altro, deve essere un assembly indipendente. Un thread interessanti su questo argomento sono presenti legata all'Overflow dello Stack in bit.ly/mUs6cv. Per ulteriori informazioni su come dividere le entità da un contesto di EF, vedere ADO.Post di blog di team netto, "Procedura dettagliata: POCO modello per l'Entity Framework" (bit.ly/bDcUoN) e "EF 4.1 modello & Database prima procedura dettagliata"(bit.ly/hufcWN).
Questa analisi, sembra che l'attributo POCO è essenziale per le classi di dominio. POCO, naturalmente, indica una classe senza dipendenze all'esterno dell'assembly. POCO riguarda la semplicità e mai è errato. Non sarà il mezzo di modo POCO con forme di accoppiamento stretto tra i livelli. Accoppiamento stretto non veleni e non kill è immediatamente, ma il progetto può richiedere una morte lenta. Check-out del mio articolo sui guasti del software nel numero del mese scorso (msdn.microsoft.com/magazine/hh394145).
Quando si crea un modello a oggetti, è possibile creare una libreria di classi. È possibile organizzare il modello a oggetti in base a un numero di serie, ma essenzialmente riduce a scelta tra un approccio orientato alla tabella e un approccio orientato.
Come si può progettare classi? Quali funzionalità dovrebbero feature? In particolare, devono essere a conoscenza del database di classi? Deve includere la logica (vale a dire metodi) oppure limitarsi ad esporre solo le proprietà? Esistono due modelli principali è possibile fare riferimento a: Record attivo e il modello di dominio.
Nel modello di Record attivo, le classi sono strettamente correlate a tabelle di database. Hai principalmente una sola classe per ogni tabella e una proprietà per ogni colonna. Le classi sono ancora più importante, responsabile per la propria persistenza e la propria logica del dominio semplice e minimo.
In base al criterio di modello di dominio, le classi sono intese a fornire una visione concettuale del dominio del problema. Queste classi non hanno alcuna relazione con il database e dispongono di metodi e proprietà. Infine, queste classi non sono responsabili per la propria persistenza. Se si opta per un approccio del modello di dominio, persistenza debba essere delegata a un livello distinto, ovvero DAL. È possibile scrivere personalmente questo livello, ma non sarebbe molto divertente. A well-Done per una libreria progettata in base al criterio di modello di dominio è praticamente uguale come strumento ORM. Perché non lo si utilizza uno degli strumenti ORM esistenti?
Soprattutto se si utilizza il generatore di codice automatico, il fattore ottiene è che un modello a oggetti è costituito da classi che presentano solo le proprietà. Il modello utilizzato non è certamente Record attivo, ma le classi non dispongono di alcun metodo per impostazione predefinita. Per fortuna, sono contrassegnate come parziale, che rende possibile per consentire di definire un modello molto più completo di dominio mediante l'aggiunta di logica attraverso le classi parziali. Se si sceglie il primo codice approccio, quindi si è interamente responsabile della scrittura del codice sorgente delle classi dall'inizio alla fine.
Le classi in un modello a oggetti che solo le proprietà della feature sono spesso definito un modello di dominio anemic.
Una buona pratica che sta acquisendo popolarità well-deserved è disposto il codice di accesso ai dati nelle classi di facciata note come repository. Un repository è costituito da un'interfaccia e una classe di implementazione. In genere dispone di un repository per ogni significativi classe nel modello. Una classe significativa in un modello a oggetti è una classe che consente di controllare la propria persistenza e indica il proprio dominio senza in base alle altre classi. In generale, ad esempio, cliente è una classe significativa, mentre OrderDetails non, in quanto si utilizzerà sempre i dettagli dell'ordine se si dispone di un ordine. In ggg, una classe significativa è definita come radice di un'aggregata.
Per migliorare la progettazione, è possibile stabilire una relazione tra la logica dell'applicazione e DAL tramite le interfacce di repository. Possibile Iniettare repository effettivo nella logica dell'applicazione in modo appropriato. Figura 2 è illustrata l'architettura risultante in cui si basa DAL repository.
.png)
Figura 2 utilizzo DAL repository
Repository attivare inserimento delle dipendenze nel livello Data Access perché è possibile scollegare il modulo corrente che fornisce la logica per la persistenza e sostituirlo con il proprio. Questo è senz'altro utile per la testabilità, ma non è limitata a quella. Un'architettura basata su repository consente di simulazione DAL e testare la logica dell'applicazione in isolamento.
Repository anche rappresentare un punto di estensibilità eccellente per le applicazioni. Se si sostituisce il repository, è possibile sostituire il motore di persistenza in modo trasparente per il resto dei livelli. Qui il punto non è in modo molto sul passaggio da, ad esempio, da Oracle a SQL Server, perché questo livello di flessibilità è già fornito dagli strumenti ORM. Il punto di questo campo è la possibilità di passare dall'implementazione corrente del livello Data Access a qualcosa di diverso, ad esempio una nuvola di API, Dynamics CRM, una soluzione di NoSQL e così via.
Un repository è parte del livello Data Access; di conseguenza, non dovrebbe per conoscere la logica dell'applicazione. Ciò potrebbe essere troppo un ovvio, ma un tipo di diagramma dell'architettura che vedo molto spesso al giorno d'oggi si basa sulla presentazione e repository.
Se la logica effettiva è sottile e semplice, ovvero o è essenzialmente CRUD, allora questo diagramma è superiore a quello di OK. Ma cosa succede se non è così? In tal caso, è necessario senza dubbio un posto nella parte centrale in cui è possibile implementare la logica dell'applicazione. E fidatevi di me, ho visto solo poche applicazioni che sono semplicemente CRUD nella mia carriera. Ma probabilmente non mi piace un uomo fortunato …
Conclusione, oggi le applicazioni tendono a essere progettato attorno al modello di dati uno strumento ORM quindi persiste per un tipo di archivio dati. Questo metodo è utile per il back-end dell'applicazione, ma è probabile che anche se l'interfaccia utente è necessario affrontare significativamente diverse funzioni di aggregazione dei dati che semplicemente non esistono nel modello originale. È necessario creare questi nuovi tipi di dati sono disponibili per il solo scopo dell'interfaccia utente. E finiscono con formando un modello a oggetti interamente parallela: il modello di visualizzazione. Se si riducono i due modelli a uno solo, quindi adeguati stick a quella e siano soddisfatti. In caso contrario, è auspicabile che in questo articolo chiarita alcuni punti poco chiari.
Dino Esposito* è anche autore di "Programming Microsoft ASP.NET MVC3 "(Mondadori informatica, 2011) e coautore di Microsoft.NET: architettura delle applicazioni per le aziende "(Microsoft Press, 2008). Vive in Italia e partecipa spesso come relatore a eventi del settore in tutto il mondo. È possibile seguire quest'ultimo movimenti in twitter.com/despos.*
Grazie ai seguenti esperti tecnici per la revisione di questo articolo:Andrea Saltarello eAmicis Diego