Il presente articolo è stato tradotto automaticamente.

Avanguardia

Vantaggi e svantaggi dei dati di oggetti di trasferimento

Dino Esposito

Contenuto

Procedure Patterns for BLL
Modelli basati sull'oggetto per BLL
Il livello di servizio
Introduzione a oggetti di trasferimento di dati
Altri vantaggi di DTOs
Svantaggi del DTOs
Riferimento a entità direttamente
Il metodo medio
Approccio misto

Quasi ogni sviluppatore e architetto necessario concordare seguenti, anche se relativamente perse, definizione del livello business logic (BLL) di un'applicazione software: il livello Business LOGIC fa parte dell'applicazione software che riguarda le prestazioni delle attività correlate al business. Codice il livello Business LOGIC agisce sui dati che tentano di entità di modello nel dominio del problema, fatture, i clienti, ordini e così via. Operazioni nel tentativo di BLL processi aziendali di modello.

Sotto le quinte di questa definizione ampiamente accettata collocarsi un numero di dettagli chiave che rimangono non definito e non specificato. Modelli di progettazione disponibili per gli architetti e progettisti di codice trasforma le definizioni separate in linee guida. In generale, modelli di progettazione BLL sono un elemento attivo leggermente diverso. Tali operazioni e i dati del modello e spesso fungere da punto di partenza per progettare il livello Business LOGIC.

In questo articolo, dopo un aggiornamento breve su modelli di procedure e basato sugli oggetti per l'organizzazione il livello Business LOGIC mi concentrerò sul uno lato del problema, gli oggetti di trasferimento dati, che se non effettivamente risolti a livello di architettura, possono avere un completo impatto sullo sviluppo del progetto.

Procedure Patterns for BLL

Per quanto riguarda il livello Business LOGIC di progettazione, è possibile avviare dai casi di utilizzo che sono emersa durante la fase di analisi. In genere, si finisce un metodo per ogni richiesta l'interazione tra l'utente e il sistema di codifica. Ogni interazione costituisce una transazione logica che include tutti i passaggi di scadenza, da input per eseguire l'attività di raccolta e dall'accesso al database per aggiornare l'interfaccia utente. Questo approccio viene definito come criterio di script di transazione (TS).

In Servizi terminal, si concentrarsi sulle azioni necessarie e si realtà non crea un modello concettuale del dominio come centro di gravitational dell'applicazione.

Per spostare i dati intorno, è possibile utilizzare tutti gli oggetti contenitore potrebbero base alle esigenze. Nella casella di Microsoft .NET questo principalmente significa utilizzare contenitori di dati ADO.NET, ad esempio DataSet e DataTable. Questi oggetti sono un tipo di oggetto super-array, con alcuni ricerca, indicizzazione e funzionalità di filtro. Inoltre, i DataSet e DataTable possano essere serializzato facilmente tra i diversi livelli e anche mantenute localmente per consentire scenari non in linea.

Il modello di Servizi terminal non imponga un modello specifico per la rappresentazione dei dati (e non impedisce qualsiasi uno). In genere, le operazioni sono raggruppate come metodi statici in uno o più classi del punto di ingresso. In alternativa, è possibile implementare le operazioni come comandi di un approccio di motivo di comando. Organizzazione dell'accesso ai dati per lo sviluppatore e comporta in genere in blocchi di codice ADO.NET.

Il modello di Servizi terminal è piuttosto semplice impostare; allo stesso tempo, ovviamente non scalabile che e, man mano che aumenta la complessità dell'applicazione. Nella casella .NET un altro modello ha ottenuto l'ampia accettazione nel corso degli anni: il modello di modulo di tabella. In poche parole, il modello di modulo tabella suggerisce una visione incentrata sui database del livello Business LOGIC. Richiede di creare un componente business per ogni tabella del database. Noto come la classe del modulo di tabella, il componente business pacchetti i dati e il comportamento tra loro.

Nel modello di modulo di tabella, il livello Business LOGIC è suddiviso in un insieme di componenti generico, ogni che rappresenta una tabella dell'intero database. Essere strettamente orientato alla tabella, il modello di modulo tabella presta a utilizzando strutture di dati simile a recordset per passare dati intorno. I contenitori di dati ADO.NET o, meglio ancora, personalizzato e tipizzata versione di ADO.NET contenitori rappresentano la scelta di naturale.

La necessità di una visualizzazione più concettuale di dominio il problema si verifica, i modelli BLL che hanno lavorato per anni nello spazio .NET necessario evoluzione alcune più. Gli architetti tendono a creare un modello di entità o relazione che rappresenta il dominio del problema e osservare le tecnologie come LINQ a SQL ed Entity Framework come strumenti concreti per.

Modelli basati sull'oggetto per BLL

Il modello di modulo tabella è basato su oggetti, ma non davvero un modello basato su oggetti per la logica aziendale di modellizzazione. Dispone gli oggetti, ma sono oggetti che rappresentano le tabelle, gli oggetti che rappresenta il dominio del problema.

In un modello orientato agli oggetti, la logica aziendale identifica le entità ed esprime tutte le interazioni richieste e consentite tra le entità. Alla fine, l'applicazione viene visualizzato come un insieme di oggetti correlati e interoperating. L'insieme di oggetti mapping entità, nonché alcuni oggetti speciali di esecuzione modulo calcoli il modello di dominio. (In Entity Framework, espressi modello di dominio utilizzando Entity Data Model [EDM]).

Esistono vari livelli di complessità in un modello di dominio che suggeriscono di modelli diversi, in genere il modello di Record Active o il modello di modello di dominio. Un metodo efficace di questa complessità è la distanza tra il modello di entità in presente e il modello dati relazionale che si intende creare per archiviare i dati. Un modello di dominio semplice è uno in cui le entità mappare strettamente a tabelle nel modello di dati. Un modello semplice, in modo non richiede il mapping a caricare e salvare gli oggetti di dominio a un database relazionale.

Il modello di record di Active è la scelta ideale quando è necessario un modello di dominio semplice, in caso contrario, quando è preferibile progettare entità e relazioni indipendentemente dalla nozione di qualsiasi database, il criterio di modello di dominio è la soluzione.

Il modello di Record Active è simile per ottenere un modello a oggetti LINQ a SQL (e il modello defaultgenerated con Progettazione entità in Entity Framework versione 1.0). A partire da un database esistente è possibile creare gli oggetti corrispondenti a una riga in una tabella di database. L'oggetto avrà una proprietà per ogni colonna della tabella dello stesso tipo e con gli stessi vincoli. La formulazione del motivo Active Record originale è consigliabile che ogni oggetto rende responsabile per la propria persistenza. Ciò significa che ogni classe di entità deve includere metodi, ad esempio Salva e carica. LINQ a SQL, né con Entity Framework viene tuttavia, un'infrastruttura integrata O/RM che funge da livello di accesso ai dati reali, come illustrato nella Figura 1 persistenza ambito della gestione entrambi delegato.

Figura 1 architettura a livelli A – PatternUsed il modello di dominio per il livello Business LOGIC

Il livello di servizio

Nella Figura 1 , è visualizzata una sezione logica di BLL denominato come il "livello di servizio" posizionato tra il livello di presentazione e il livello che si occupa di persistenza. In poche parole, il livello di servizio definisce un'interfaccia per il livello di presentazione attivare azioni predefinite di sistema. Il livello di servizio separa la presentazione e logica aziendale e rappresenta l'aspetto per la logica di presentazione per la chiamata al livello Business LOGIC. Il livello di servizio non proprio processo, regardless of la logica aziendale è organizzata internamente.

Gli sviluppatori .NET si ha piuttosto familiarità con i gestori eventi in Web o di Windows Form. Il metodo Button1_Click canonico appartiene al livello di presentazione ed esprime il comportamento del sistema dopo che l'utente ha fatto clic un determinato pulsante. Comportamento del sistema, più precisamente, nel caso di utilizzo si sta implementando, potrebbe richiedere alcuni l'interazione con componenti del livello Business LOGIC. In genere, è necessario creare un'istanza del componente del livello Business LOGIC e quindi creare degli script. Il codice necessario per il componente di script può essere semplice come chiamare il costruttore e forse un metodo. Più spesso, tuttavia, tale codice è piuttosto RTF con diramazioni e potrebbe essere necessario chiamare in più oggetti o attendere una risposta. Gli sviluppatori che la maggior parte delle fare riferimento il codice come logica dell'applicazione. Di conseguenza, il livello di servizio è la posizione in BLL in cui memorizzare logica dell'applicazione, mantenendo distinto e separato dalla logica di dominio. La logica di dominio è una logica di che piegare nelle classi che rappresentano entità di dominio.

Nella Figura 1 , blocchi di modello di livello e il dominio servizio sono distinti al livello Business LOGIC, sebbene sia probabile che appartengono a assembly diversi. Il livello di servizio conosce il modello di dominio e fa riferimento all'assembly corrispondente. Assembly del livello del servizio, al contrario, viene fatto riferimento dal livello di presentazione e che rappresenta il solo punto di contatto tra qualsiasi livello di presentazione (essere Windows, Web, Silverlight o cellulare) e il livello Business LOGIC. la figura 2 Mostra il grafico di riferimenti che si connettono gli attori diversi. Il livello di servizio è una sorta di mediatore tra il livello di presentazione e il resto del livello Business LOGIC. Di conseguenza, ne perfettamente separati, ma con accoppiamento ridotto in modo che siano perfettamente in grado di comunicare. Nella Figura 2 , il livello di presentazione non contiene alcun riferimento all'assembly modello di dominio. Questa è una scelta di progettazione chiave per le soluzioni a più livelli.

Nella figura 2 diagramma dei riferimenti tra gli attori partecipante

Introduzione a oggetti di trasferimento di dati

Quando si dispone di una visione basato sul dominio dell'applicazione, è impossibile Guida ma aspetto seriamente in dati di oggetti di trasferimento. Nessuna soluzione a più livelli, basata su LINQ to SQL o di Entity Framework non è immune da questo problema di progettazione. La domanda è come è possibile spostare i dati da e verso il livello di presentazione? In altre parole, deve essere il livello di presentazione mantenere un riferimento all'assembly del modello di dominio? (In uno scenario di Entity Framework, l'assembly del modello di dominio è solo la DLL creata all'esterno del file EDMX.)

La struttura dovrebbe in teoria, simile alla Figura 3 , in cui gli oggetti made-to-measure vengono utilizzati per passare i dati dal livello presentazione il livello di servizio e il backup. Questi oggetti contenitore ad hoc assumono il nome di oggetti di trasferimento di dati (DTOs).

Nella figura 3 comunicazioni tra livello di presentazione andService Layer

Un DTO è niente di più di una classe contenitore che espone le proprietà, ma nessun metodo. Un DTO è utile quando è necessario valori di gruppo in strutture ad hoc per passare dati intorno.

Dal punto di vista Progettazione pure DTOs rappresentano una soluzione realmente vicino alla perfezione. DTOs consentono di separare ulteriormente la presentazione dal livello di servizio e il modello di dominio. Quando vengono utilizzati DTOs, il livello di presentazione e il livello di servizio condividere i contratti di dati anziché le classi. Un contratto di dati è essenzialmente una rappresentazione non associate ad alcun paese dei dati che interagiscono i componenti di exchange. Il contratto dati descrive i dati che riceve un componente, ma non è una classe di sistema specifiche, come un'entità. Alla fine del giorno, un contratto di dati è una classe, ma è più simile a una classe helper creata appositamente per un metodo di servizio specifico.

Un livello di DTOs isola il modello di dominio della presentazione, che sia accoppiamento e trasferimento di dati ottimizzato.

Altri vantaggi di DTOs

L'adozione di contratti dati aggiunge una buona dose di flessibilità al livello di servizio e, successivamente, alla struttura dell'intera applicazione. Ad esempio, se DTOs vengono utilizzati, una modifica dei requisiti di uno spostamento impone una quantità di dati non dispone di alcun impatto sul livello di servizio o anche il dominio. È modificare la classe DTO coinvolta aggiungendo una nuova proprietà, ma lasciare intatto l'interfaccia globale di livello di servizio.

È importante notare che la presentazione è probabile che una modifica indica una modifica in uno dei casi utilizzare e quindi nella logica dell'applicazione. Poiché il livello di servizio esegue il rendering la logica dell'applicazione, in questo contesto una modifica nell'interfaccia di livello di servizio è comunque accettabile. Tuttavia, nella mia esperienza, modifiche ripetute l'interfaccia di livello di servizio possono portare a termine errato che le modifiche agli oggetti del dominio di, le entità, potrebbe essere di salvare ulteriori modifiche nel livello di servizio. Questo non accade in team well-disciplined o quando gli sviluppatori dispone di una conoscenza approfondita della separazione dei ruoli che esiste tra il modello di dominio, il livello di servizio e DTOs.

Come illustrato dalla Figura 4 , quando vengono impiegate DTOs, è inoltre necessario un livello di scheda DTO per adattare uno o più oggetti entità a un'interfaccia diversa come richiesto dallo use case. In tal modo, è effettivamente implementare il modello "Dispositivo", uno dei motivi progettazione più diffusi e classica. Il modello di scheda, essenzialmente, converte l'interfaccia di una classe in un'altra interfaccia che prevede un client.

Nella figura 4 schede DTO nel livello Business LOGIC

Con riferimento a Nella figura 4 , il livello della scheda è responsabile per la lettura di un'istanza in ingresso della classe OperationRequestDTO e della creazione e inserimento di nuove istanze di OperationResponseDTO.

Quando i requisiti di modifica e forzare le modifiche in un livello di servizio basato su DTO, è sufficiente è aggiornamento i dati pubblica contratto del DTO e regolare la scheda DTO corrispondente.

I vantaggi offerti da DTOs decoupling non terminano qui. Inoltre, per fortuna sopravvivenza della presentazione, le modifiche apportate è possibile immettere le modifiche apportate alle entità nel modello di dominio senza alcun impatto sugli qualsiasi client che sarà necessario.

Qualsiasi modello di dominio realistico contiene relazioni, ad esempio ordini per clienti e ordini per cliente, che costituiscono un collegamento tra le entità Customer e Order doppio. Con DTOs, è anche aggirare il problema della gestione di riferimenti circolari durante la serializzazione di oggetti di entità. È possibile creare DTOs per eseguire un flusso piatto di valori che, se necessario, serializzare solo fine eventuali limiti. (Si verrà ritorna a questo punto in un momento.)

Svantaggi del DTOs

Dal punto di vista Progettazione pure DTOs sono un reale vantaggio, ma è questo punto teorico confermato dalla pratica, troppo? Come in molti punti aperto di architettura, la risposta è, da cui dipende.

Centinaia di entità nel modello di dominio è un buon motivo per alternative prendendo in considerazione a un approccio basato su DTO puro. Nei progetti di grandi dimensioni con molte entità DTOs aggiungere un notevole livello di complessità (supplementare) e operazioni da eseguire. In breve, pure, 100 % DTO soluzione è spesso solo una soluzione più complesso di 100 %.

Sebbene normalmente la complessità aggiunto a una soluzione da DTOs viene misurata con la cardinalità del modello di dominio, il numero reale di DTOs necessarie può essere a che più affidabile determinata esaminando i casi di utilizzo e l'implementazione del livello di servizio. Una formula valida per la stima quanti DTOs è necessario consiste nell'esaminare il numero di metodi nel livello di servizio. Il numero reale può essere inferiore se è possibile riutilizzare alcuni DTOs più chiamate del livello di servizio, o superiore se DTOs il gruppo di alcuni dati utilizzando i tipi complessi.

In sintesi, l'argomento solo con utilizzando DTOs è ulteriori operazioni necessarie per scrivere e gestire il numero di classi DTO risultanti. Non è, tuttavia, un semplice importante di pigrizia un programmatore. Nei progetti di grandi dimensioni, separazione di presentazione dal livello di servizio costi è centinaia di nuove classi.

Va inoltre sottolineato che un DTO non è semplicemente una copia lightweight di ogni entità che è necessario. Si supponga che due casi di utilizzo distinti occorre di restituire un insieme di ordini, ad esempio, GetOrdersByCountry e GetOrdersByCustomer. Molto probabilmente, le informazioni da inserire in "order" sono diverse. È probabilmente necessario GetOrdersByCustomer più in GetOrdersByCountry dettagli ulteriori (o meno). Ciò significa che DTOs distinte sono necessarie. Per questo motivo, centinaia di entità è certamente una misura rapida di complessità, ma può determinare il numero reale di DTOs solo esaminando i casi di utilizzo.

Se DTOs non sono sempre ottimali, quale sarebbe una valida alternativa?

L'unica alternativa all'utilizzo di DTOs è per fare riferimento l'assembly del modello di dominio da all'interno del livello presentazione. In questo modo viene tuttavia, stabilire un accoppiamento stretto tra livelli. E livelli di accoppiamento potrebbero essere un problema ancora peggio.

Riferimento a entità direttamente

Una condizione, non in modo ovvia per attivare il collegamento di entità direttamente dal livello di presentazione è che è accettabile per il livello di presentazione ricevere i dati nel formato di oggetti di entità. La presentazione deve talvolta dati formattati in un modo particolare. Un livello di scheda DTO esiste solo il massaggio dati come richiesto dal client. Se tuttavia non si utilizza DTOs, deve essere spostato l'onere della formattazione dei dati correttamente nel livello di presentazione. In effetti, nella posizione sbagliata in cui per formattare i dati per scopi di interfaccia utente è il modello di dominio.

È possibile eseguire in modo realistico, senza DTOs solo se il livello di presentazione e il livello di servizio sono risiedere stesso sistema nello stesso processo. In questo caso, è possibile fare facilmente riferimento all'entità assembly da in entrambi i livelli senza affrontare problemi spinosa, ad esempio i servizi remoti e i dati di serializzazione. Questa considerazione conduce a un'altra buona domanda: dove necessario adattare il livello di servizio?

Se il client è una pagina Web, il livello di servizio è preferibilmente locale al server Web che ospita la pagina. Nelle applicazioni ASP.NET, il livello di presentazione è in classi code-behind e si trova accanto al livello di servizio nello stesso AppDomain. In questo caso, ogni comunicazione tra il livello di presentazione e il livello di servizio si verifica in corso, e gli oggetti possono essere condiviso con worries non ulteriormente. Le applicazioni ASP.NET sono uno scenario valido in cui è possibile provare una soluzione che non utilizza il livello aggiuntivo di DTOs.

Technology-Wise, è possibile implementare il livello di servizio tramite gli oggetti .NET semplici oppure tramite i servizi Windows Communication Foundation (WCF) locale. Se l'applicazione ha esito positivo, è possibile aumentare facilmente scalabilità spostando il livello di servizio a un server applicazioni separato.

Se il client è un'applicazione desktop, il livello di servizio è in genere distribuito a un livello diverso e accedere in remoto dal client. Purché sia il client e il server remoto condividono la stessa piattaforma. NET, è possibile utilizzare i servizi remoti tecniche (o meglio, I servizi WCF) per implementare la comunicazione e ancora utilizzare oggetti di entità nativo su entrambe le estremità. L'infrastruttura WCF verrà prendersi cura di marshalling dei dati tra i diversi livelli e pump in copie di entità nativa. Inoltre, in questo caso è possibile disporre un'architettura che non utilizza DTOs. Operazioni modificare in modo significativo se le piattaforme client e server non sono compatibili. In questo caso, non avete alcuna possibilità di collegare gli oggetti nativi e richiamarli dal client; successivamente, è in uno scenario puro orientato ai servizi e l'utilizzo di DTOs è la possibilità di sola.

Il metodo medio

DTOs sono l'oggetto di una scelta di progettazione importante che riguarda l'implementazione delle comunicazioni tra la presentazione e il back end del sistema.

Se si utilizza DTOs, è possibile mantenere il sistema loosely coupled e aperta verso numerosi client di posta. DTOs rappresentano la scelta ideale, se si è in grado si. DTOs aggiungere un significativo programmazione overhead a qualsiasi sistema reale. Questo non significa che DTOs non deve essere utilizzato, ma portare a una proliferazione di classi che è effettivamente possibile prefigure un incubo di manutenzione nei progetti con alcuni oggetti di entità centinaia e casi di utilizzo ancora più.

Se ci si trova lo stesso tempo un provider e consumer del livello di servizio, e se si dispone di controllo completo della presentazione, potrebbero essere vantaggi in fa riferimento all'assembly del modello di entità dalla presentazione. In questo modo, tutti i metodi nel livello di servizio possono utilizzare le classi di entità come i contratti di dati delle relative firme. L'impatto sulla progettazione e codifica è chiaramente molto più "morbido".

Se utilizzare DTOs o non è non un punto facile da generalizzare. Per essere efficace, la decisione finale dovrà essere sempre eseguita esaminando i dettagli del progetto. Alla fine, un approccio misto è probabilmente ciò che procedura nella maggior parte dei casi. Personalmente, tendono a utilizzare le entità come è possibile. Ciò si verifica non perché mi contro purezza e nuova progettazione, ma per una questione più semplice di pragmatism. Un modello di entità conti per entità solo 10 e in alcuni casi di utilizzo, tramite DTOs completamente tramite non comportare alcun problema. E ottenere ben struttura basso l'accoppiamento. Tuttavia, con centinaia di entità e utilizzare casi, il numero reale di classi per scrivere, gestiscono e test ominously si avvicina l'ordine delle migliaia. Qualsiasi possibile riduzione della complessità che soddisfi i requisiti è maggiore di benvenuto.

I progettisti, tuttavia, è sempre necessario sull'avviso per riconoscere il segno che indica che la distanza tra il modello di entità e ciò che prevede la presentazione è significativo se non Impossibile coprire. In questo caso, è necessario adottare la route più sicura (e pulitura) DTOs.

Approccio misto

Applicazioni a più livelli di oggi riservano una sezione di BLL al livello di servizio. Il livello di servizio (noto anche come livello di applicazione) contiene la logica dell'applicazione; vale a dire i regole di business e le procedure sono specifiche per l'applicazione ma non per il dominio. Un sistema con più server front-end esporrà una singola porzione di logica di dominio tramite le classi di entità, ma quindi ogni front end avrà un livello di business aggiuntive specifico per i casi di utilizzo che supporta. Questo è ciò che viene definito il livello di servizio (o applicazione).

Attivato dall'interfaccia utente, la logica dell'applicazione script le entità e i servizi nella logica di business. Nel livello di servizio, è necessario implementare i casi di utilizzo ed esporre ogni sequenza di passaggi tramite un metodo generico chiamare la presentazione.

Nella struttura del livello di servizio, si desideri applicare poche procedure consigliate, adottare orientamento ai servizi e condividere i contratti dati anziché le classi di entità. Mentre questo approccio è ideale in teoria, spesso conflitto con il mondo reale, come l'aggiunta di progetti con centinaia di entità e casi di utilizzo eccessivo sovraccarico alla fine.

Si scopre che un approccio misto che utilizza dati contratti solo quando utilizzando le classi non è possibile, è spesso la soluzione più accettabile. Ma come un architetto software, è necessario non questa decisione leggermente. Violazione regole di buona progettazione è consentita, purché si conosce ciò che si sta eseguendo.

Per inviare domande e commenti a Dino per indirizzo cutting@microsoft.com.

Dino Esposito è un architetto presso IDesign e coautore di Microsoft .NET: Architecting Applications for the Enterprise (Microsoft Press, 2008). In base a in Italia, Dino è spesso come relatore a eventi del settore in tutto il mondo. È possibile unire il suo blog all' weblogs.ASP. net/despos.