DDD Concetti nello sviluppo N-Strato

Question

Dopo aver trascorso un paio di mesi a studiare la metodologia DDD, ora ho cominciato ad applicare questi concetti in prodotti reali alla mia azienda. In realtà, io sono stato incaricato di creare un'architettura adatta e gestibile per lo sviluppo futuro.

Abbiamo deciso di avvalersi delle seguenti tecnologie: EF4 (davvero v2), Unità

La quantità di informazioni che ho ottenuto è stato più illuminante, però, mi sono lasciato con molte domande a best practice:

Domanda # 1: DTOs - Best Practices

Ho i miei oggetti di dominio (classi POCO). Ci sono diversi modi per implementare queste classi.

1. approccio tradizionale: creare classi POCO che contengono pubblici getter / setter, validazione, e la logica di business adeguato. Anche creare DTOs e utilizzare tecniche di mappatura per la loro gestione. (Automapper)
2. Tradizionale - DTO: Creare classi POCO come detto sopra, tuttavia, utilizzare le Pocos come oggetti di trasferimento. E 'la mia comprensione che gli oggetti di business non dovrebbero mai lasciare il dominio però.
3. Hybrid: Sono incappato in un interessante post sul blog in cui l'autore crea i suoi oggetti POCO e DTOs. All'interno del suo oggetto dominio crea un'istanza del DTO. Questo consente una più facile manutenzione, come non si è duplicare le proprietà come in # 1. In questo modo:

public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{

 public T Data { get; set; }

 public POCOBase()
 {
     Data = new T();
 }

 public POCOBase(T dto)
 {
     Data = dto;
 }
  }

  public class SomePOCO : POCOBase { }

  public class SomeDTO : DTOBase

  {

 public String Name { get; set; }

 public String Description { get; set; }

 public Boolean IsEnabled { get; set; }
}


// EXAMPLES
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// return somePOCO.Data;

Domanda # 2:? Quali oggetti dovrebbe essere restituito dal livello di UI / Servizio

Questo è il punto di tutta la DTO. Un molto semplice, leggero oggetto contenente solo gli attributi nude. Non è anche contenente tutti i risultati di convalida in esso. Se sto serializzazione miei DTOs al client, si deve supporre il cliente ha bisogno di alcun risultato di convalida come una collezione InvalidRules.

Per esempio, dire che sto lavorando con API di Amazon. Vorrei aggiungere un libro al mio deposito personale. Se cerco di aggiungere un libro senza inviare la sua ISBN, il servizio sarebbe probabilmente tornare una sorta di gruppo di risposta che contiene errori di convalida dei risultati.

Mi sto perdendo qualcosa? Ho avuto l'impressione (almeno da ddd "puristi"), che DTOs devono contenere alcuna logica di business. Mi sembra DTOS non forniscono informazioni sufficienti come oggetti di trasferimento. Uno che o ho bisogno di un nuovo tipo di oggetto Response che incapsula il DTO e risultati di convalida.

Domanda # 3:? Quanto IoC è troppo

Mi sembra evidente per me che devo seguire la regola d'oro:

  

"Identificare le parti dell'applicazione   che variano, e separati da quelli   che rimangono le stesse ".

Per me questo ha un senso in termini di applicazione di CIO. Per ridurre le dipendenze, la mia presentazione, Business Logic e strati di accesso ai dati tutti comunicano tramite un contenitore CIO. Il mio livello di applicazione contiene interfacce e astrazioni comuni. Sembra eccessivo usare IoC molto più di questo. Mi piace il fatto che posso creare repository test di simulazione - e semplicemente cambiando la configurazione di Unity, posso fare uso di TDD

.

Spero di aver affermato chiaramente a queste domande. Grazie per il vostro aiuto in anticipo!

Answer 1

Cercherò di rispondere alle tue domande una alla volta.

Risposta 1

DTOs sono ortogonali DDD perché servono uno scopo diverso in un luogo diverso nell'architettura di un'applicazione. Detto questo, DTOs non hanno posto in un modello di dominio perché non hanno un comportamento e sarà quindi portare a Models Anemic dominio .

pocos con persistenza L'ignoranza è la strada da percorrere. Jeremy Miller ha una buona che spiega questo concetto .

Risposta 2

I livelli che si trovano sulla parte superiore del modello di dominio avrà spesso bisogno di restituire i propri oggetti che sono su misura per lo scopo in questione.

Per interfacce utente, il modello MVVM funziona particolarmente bene. Questo articolo introduce MVVM per WPF, ma il modello funziona anche come un fascino in ASP.NET MVC.

Per i servizi web, questo è dove si applica il modello DTO. I contratti WCF Data sono DTOs, nel caso ve lo stiate chiedendo:)

Ciò richiederà un sacco di mappatura che va avanti e indietro tra l'interfaccia di servizio e il modello di dominio, ma questo è il prezzo che si deve pagare per Supple Design. Si possono trovare automapper utile a questo proposito.

Risposta 3

Il più CIO (davvero: DI) è il migliore, ma una cosa sulla tua domanda mi ha colpito: A DI contenitore deve collegare solo il grafico oggetto e poi uscire di strada. Gli oggetti non dovrebbero fare affidamento sul DI Container.

questo SO rispondere per maggiori dettagli.