passaggio di dati in un'applicazione nTier

Question

Come si fa a passare dati a strati in un'applicazione a più livelli? Ho tracciato 3 metodi differenti.

A) oggetti .NET generica tabelle di dati generici, tabelle hash, set di dati generici, stringhe, ints ecc ... quindi utilizzando i dataset per riempire gli oggetti di business che vengono inviati al livello di interfaccia utente.

alt http://img11.imageshack.us/img11/460/generic testo. png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro - Non ci sono strati extra necessaria Con - deve lavorare con set di dati generici e tavoli in strato di business

B) utilizzando uno strato entità che gli altri strati avrebbero riferimento. Questo strato dovrebbe contenere entrambi i set di dati fortemente tipizzati o Plain Old C Objects. Gli oggetti potrebbero essere principalmente dati Contenitore e molto poco logica. questi sarebbero gli stessi oggetti inviati allo strato di interfaccia.

alt text http://img8.imageshack.us/img8/6454/entities. png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

Pro - a lavorare con le stesse classi di tutti i livelli Con - l'aggiunta di un riferimento a entities.dll a tutti i livelli

C) utilizzare oggetto di trasferimento dati (oggetti conatiner solo) definiti nello strato DataAccess. quindi utilizzando quegli oggetti per riempire gli oggetti di business che vengono inviati al livello di interfaccia utente.

alt http://img43.imageshack.us/img43/1236/transferp testo. png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

Pro - lo strato di business non sarebbe lavorare con classi generiche Con - a lavorare con due tipi di oggetti e si dovrebbe idratare gli oggetti di business con gli oggetti di trasferimento

Abbiamo avuto una discussione sul posto di lavoro e volevo vedere ciò che la comunità pensava. Ho anche aggiunto un link alla Dabbleboard. Si prega di copiare e creare invece di editing.
Grazie

Answer 1

Se stai usando un stratificato approccio, cioè tutti i livelli sono (essenzialmente) in esecuzione nello stesso spazio di processo e non v'è quindi alcun marshalling / serializzazione, mi piacerebbe andare con approccio B. Creare un modulo separato per le entità su cui tutti gli aspetti del vostro programma dipendono, e di coppia a quello.

Se, tuttavia, si sta utilizzando un a più livelli approccio come suggerisce il titolo, significa che ci sono i limiti del processo e / o di rete che si incrociano, io suggerirei di andare con l'approccio C. È 'non ri davvero passando casi in giro, si sta passando le copie, in modo da tutti i benefici che si ottengono per l'accoppiamento allo stesso oggetto, come le opzioni osservabili per, diciamo, un approccio MVC, si perdono comunque. Meglio definire le API di dati ad ogni livello tier che cercare di utilizzare la stessa classe tutto intorno.

Answer 2

Grande questione -. Come sempre, la risposta deve essere "dipende"

Il tipo di applicazione, e se c'è davvero la necessità di avere oggetti di business (entità), al contrario di trasferire gli oggetti (ad esempio gli oggetti di business dumbed-down che corrispondono più alle entità di database).

Tradizionalmente, avrei sostenuto che avete sempre bisogno di insiemi di dati generici (o tabelle di dati), esclusivamente per motivi di prestazioni. Ogni volta che v'è la necessità di lavorare con, esposizione, o manipolare set più grandi, il tradizionale modo OO rigorosa di istanziare un gran numero di oggetti di business non riuscita.

Tuttavia, da quando ho iniziato a lavorare con LINQ to SQL, i miei paradigmi sono cambiati. Non c'è più bisogno di questo a tutti, dal momento che il modello LINQ può essere tutto - gli oggetti di business, oggetti di trasferimento, e set di dati generici. Non ho ancora esplorato quanto bene funziona davvero in applicazioni di grandi dimensioni, e se ci dovrebbe essere una necessità di isolare il codice front-end dal modello LINQ. Ho avuto discussioni al riguardo con i colleghi, senza veramente trovare una risposta in entrambi i casi.

Answer 3

Mi piace l'opzione C ma dà anche a me una pausa per due motivi:

1. Devo diffondere la knwowledge di ciò che i properites sono in troppi luoghi.
2. DTO devono essere serializzabile, che non è terribile, ma ancora una considerazione.

Answer 4

Io parto dal presupposto tutti i 3 strati esiste all'interno della stessa applicazione. In Java atleast ho usato Hibernate per l'accesso dei dati e usato quelle bean di dati in tutti gli strati. (Opzione B) Ha senso essere in grado di riutilizzare le entità i livelli.