Utilizzo delle fabbriche nei presentatori in un modello View Presenter e Domain Driven Design Project

Question

Nella progettazione guidata dal dominio, sembra essere una buona pratica utilizzare Fabbriche per creare oggetti di dominio nel proprio livello di dominio (anziché utilizzare un costruttore diretto o IoC).

Ma che dire dell'utilizzo delle fabbriche di oggetti di dominio in un livello presentatore. Ad esempio, supponiamo che stavo creando un oggetto dominio dall'input dell'utente ottenuto dal presentatore.

Ecco un esempio, supponiamo che io abbia un oggetto Dominio di configurazione che ha un numero di impostazioni decimali.

Configurazione di classe pubblica: PersistantObject {

 public decimal temperature {get;set;}

 ...(times 20)

 public decimal gravity {get;set;}

}

Per creare questo oggetto nel livello del dominio, piuttosto che nel livello del presentatore, dovrei passare ciascuno di questi valori decimali come parametri di funzione. Creazione di una definizione e chiamata di funzioni ingombranti.

ie ConfigurationService.CreateConfiguration (temperatura, ... (x20), gravità);

La soluzione forse migliore sarebbe quella di creare l'oggetto Configuration nel livello presentatore e assegnare tutti i valori dell'oggetto di configurazione direttamente dall'input dell'utente, saltando una lunga chiamata di funzione.

Configuration config = ConfigurationFactory.CreateNewConfiguration ();

config.temperature = temperature;

.. (x20) .. = ...;

config.gravity = gravità;

ConfigurationService.SaveNewConfiguration (config);

Ma mi chiedo se questo approccio sia sbagliato e perché? Se entrambi questi approcci sono sbagliati, qual è l'approccio migliore per creare un oggetto lungo dall'input dell'utente e perché?

Grazie!

Answer 1

Ti sconsiglio di far uscire gli oggetti del tuo dominio dal livello del dominio e nel livello della presentazione. Mantieni il livello di presentazione focalizzato sulla presentazione.

Per questo motivo, costruisco Data Transfer Objects per mescolare i dati da e verso il dominio e i livelli di presentazione. Nel tuo caso, fai in modo che la finestra di dialogo compili un DTO che viene passato al tuo servizio e tradotto nell'oggetto dominio corrispondente.

Tuttavia, non vorrai mai costruire oggetti di dominio dai DTO. Considerare il caso in cui un DTO rappresenta solo un sottoinsieme di un oggetto dominio . Ricostruire un oggetto di dominio esistente da tale DTO ti darebbe un oggetto di dominio parziale. Probabilmente vorresti mantenere una cache leggera che contenesse l'intero oggetto del dominio in modo da poter fare un aggiornamento adeguato.

Essenzialmente, arriveresti alla soluzione DTO se applicassi Introduce Parameter Object refactoring.

Answer 2

Ci sono due modi principali per gestirlo

1) Se questo è impostato tramite una finestra di dialogo, creerei delle classi che implementano il modello di comando e assocerei una finestra di dialogo con l'oggetto in questione. Ad esempio CmdCreateConfigurationService e CmdEditConfigurationService.

CmdCreateConfigurationService si affiderebbe a una classe di fabbrica e ai parametri minimi necessari per selezionare il servizio di configurazione corretto.

Si imposta un'interfaccia IConfigurationServiceEditor e la si passa come uno dei parametri ai parametri CmdEditConfiguration. Con l'interfaccia IConfigurationServiceEditor definisci tutti i metodi di cui hai bisogno per rendere il trasferimento di informazioni da e verso la finestra di dialogo il più semplice e indolore possibile. Consiglio di utilizzare una raccolta di chiavi e valori. L'oggetto comando sa come impostare il servizio di configurazione da questa raccolta. La finestra di dialogo sa di aspettarsi questa raccolta durante l'installazione.

Indipendentemente dalla struttura dei dati, eseguirai il lavoro di compilazione del servizio di configurazione nell'oggetto comando. Avendo un oggetto non dialog / form / screen implementare IConfigurationServiceEditor è possibile automatizzare i test e in alcune circostanze semplificare la configurazione di oggetti complessi.

Ho sviluppato questo metodo per un software CAD / CAM che ha diverse dozzine di forme parametriche ognuna con da 4 a 40 voci.