passaggio di dati in un'applicazione ntier

Question

Come si passano i dati ai livelli in un'applicazione n-tier? Ho mappato 3 diversi metodi.

A) oggetti .net generico tavoli generici di dati, Hashtables, set di dati generici, stringhe, ecc ... ints quindi utilizzando i dataset per riempire gli oggetti di business che vengono inviati al livello di interfaccia utente.

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

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

Pro- Nessun strati extra necessario Con- devono lavorare con set di dati generici e tavoli in strato di business

B) usando un livello di entità che gli altri strati w potrebbe riferimento. Questo strato conterrebbe dataset fortemente tipizzati o Plain Old C Objects. Gli oggetti sarebbero per lo più dati contenitore e molto poca logica. questi sarebbero gli stessi oggetti inviati al livello dell'interfaccia utente.

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

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

Pro- lavorare con le stesse classi in tutti gli strati Con- aggiunge un riferimento alla entities.dll a tutti i livelli

C) utilizzare oggetti di trasferimento dati (oggetti cono nly) definito nel livello DataAccess. quindi utilizzare tali oggetti per riempire gli oggetti di business che vengono inviati al livello dell'interfaccia utente.

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

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

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

Abbiamo avuto una discussione sul lavoro e volevo vedere cosa pensava la comunità. Ho anche aggiunto un link al dabbleboard. per favore copia e crea invece di modificare.
Grazie

Answer 1

Se si utilizza un approccio stratificato , ovvero tutti i livelli sono (in sostanza) in esecuzione nello stesso spazio del processo e quindi non esiste marshalling/serializzazione, andrei con l'approccio B. Creare un modulo separato per le tue entità da cui dipendono tutti gli aspetti del tuo programma, e accoppiato a quello.

Se, tuttavia, si sta utilizzando un approccio a più livelli come il titolo suggerisce, significa che ci sono i limiti del processo e/o di rete che si incrociano, io suggerirei di andare con l'approccio C. Tu non sei veramente passando le istanze in giro, si passano copie, quindi tutti i benefici che si ottengono nell'accoppiamento allo stesso oggetto, come le opzioni osservabili per, ad esempio, un approccio MVC, vengono persi comunque. È meglio definire API di dati a tutti i livelli piuttosto che provare a utilizzare la stessa classe in tutto il mondo.

Answer 2

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

1. devo diffondere il knwowledge di ciò che i properites sono in troppi luoghi.
2. I DTO devono essere serializzabili, il che non è terribile, ma è comunque una considerazione.

Answer 3

Suppongo che tutti i 3 livelli siano presenti nella stessa app.In java atleast ho usato Hibernate per l'accesso ai dati e ho usato quei bean di dati in tutti i livelli. (opzione B) Ha senso essere in grado di riutilizzare le tue entità nei tuoi livelli.

Answer 4

Grande domanda - come sempre, la risposta deve essere "dipende".

Sul tipo di applicazione, e se sia davvero necessario disporre di oggetti di business (Entità), al contrario di oggetti di trasferimento (ad esempio oggetti business imbrogliati che corrispondono più a entità di database).

Tradizionalmente, avrei sostenuto che è sempre necessario disporre di set di dati generici (o tabelle di dati), puramente per motivi di prestazioni. Ogni volta che vi è la necessità di lavorare, visualizzare o manipolare insiemi più grandi, il tradizionale modo OO rigoroso di istanziare un gran numero di oggetti business non è riuscito.

Tuttavia, da quando ho iniziato a lavorare con Linq su SQL, i miei paradigmi sono cambiati. Non è più necessario, poiché il modello Linq può essere tutto: oggetti di business, oggetti di trasferimento e set di dati generici. Non ho ancora esplorato quanto bene funzioni in applicazioni veramente grandi e se sia necessario isolare il codice front-end dal modello Linq. Ho discusso con i colleghi, senza trovare una risposta in entrambi i casi.