Perché così tanti livelli con oggetti simili a domainobject in un'applicazione?

Question

Perché così tanti livelli con oggetti simili a domainobject in un'applicazione?

#1 da (1 voti)

3

Ad esempio, applica una tipica applicazione Silverlight Line-of-Business. In primo luogo, abbiamo una tabella Product nel database, che contiene campi di ID, Nome, Prezzo, ecc.

Quindi, sul lato server, dovremmo avere una classe Product Entity nel Data Access Layer, che ha proprietà di ID, Name, Price, ecc;

Quindi, dovremmo avere una Product DTO Class con proprietà di ID, Name, Price, ecc; Quindi, sul lato client (Silverlight), abbiamo la classe Product DTO con proprietà di ID, Name, Price, ecc. Come contratto dati per comunicare con il server;

Quindi, dovremmo avere una Product ViewModel Class, che alse ha le proprietà di ID, Name, Price, ecc per legare con la View.

Questi numerosi livelli di oggetti simili non violano il principio Non ripetere te stesso?

Cosa succede se il modello di dominio aziendale stesso subisce frequenti cambiamenti? Ad esempio, il cliente desidera rimuovere / aggiungere nuove proprietà al prodotto, il che farà sì che tutti i livelli cambino il suo codice.

Introduciamo un livello DAL addizionale nell'ipotesi che il database sottostante venga modificato, ma nel mondo reale, il modello di business stesso cambia molto più frequentemente dell'accesso ai dati o della logica di presentazione.

design architecture silverlight

posta TomCaps 31.08.2011 - 11:38

fonte

1 risposta

Leggi altre domande sui tag design architecture silverlight

L'algoritmo Eastern PKUFFT ha battuto FFTW3 (FFT più veloce a ovest) di 20 volte? Quali sono gli algoritmi più comuni nel campo della geometria computazionale? [chiuso]

score 1 · Accepted Answer

Doesn't the so many layers of Domain-like Object violate the Don't Repeat Yourself principle?

Sì, lo fa. Ecco perché dovresti avere generatori di codice per creare automaticamente le classi necessarie dai metadati. Basta mantenere i metadati in un'unica posizione e creare automaticamente le classi quando necessario. Le classi parziali di C # possono notevolmente aiutare tali compiti, ad esempio, in modo da avere un posto per la personalizzazione. A volte altri schemi possono essere utili per evitare ripetizioni inutili: proxy dinamici o wrapper, ad esempio.

Then, We should have a Product ViewModel Class,which alse has the properties of ID,Name,Price,etc to binding with the View.

Bene, in un ViewModel puoi sempre avere la tua entità e quindi collegarti direttamente ad essa. A rigor di termini, viola la legge di Demetra ma in tali casi è accettabile. Basta esporre l'entità e non ripetere i suoi campi. Sii pragmatico.

Then, on the client(Silverlight) side, we have the Product DTO class with properties of ID,Name,Price,etc as Data Contract to communicate with the server;

Di solito hai le classi DTO in un assembly che sia il server che il client possono fare riferimento. Quindi non avrai sempre bisogno di duplicare le classi.

Inoltre: fai attenzione al termine oggetto simile a un dominio. Gli oggetti di dominio sono gli oggetti puri del dominio aziendale e non gli ausiliari tecnici degli altri livelli.

Why so many layers with domainobject like objects in an application?

Infine, per rispondere alla domanda l'intestazione: Necessità tecniche. Se esiste un campo logico aziendale, deve semplicemente esistere in varie forme. Se deve essere persistente, deve esserci una struttura che possa tenerlo permanentemente. Questa struttura deve essere definita in un modo o nell'altro. Forse anche altre applicazioni funzioneranno con quei dati. Quindi deve essere indipendente dalle strutture già definite nella tua applicazione. La stessa cosa per i DTO. Sono costruiti per comunicare i dati tra (sotto) sistemi.