Utilisation des usines dans les présentateurs dans une vue modèle Projet de conception par présentateur et par domaine

Question

Dans la conception pilotée par domaine, il semble être judicieux d’utiliser des factories pour créer vos objets de domaine dans votre couche de domaine (par opposition à un constructeur direct ou IoC).

Mais qu’en est-il de l’utilisation des fabriques d’objets du domaine dans une couche de présentation. Par exemple, supposons que je crée un objet de domaine à partir d'une entrée utilisateur obtenue du présentateur.

Voici un exemple, disons que j’ai un objet de domaine de configuration avec un certain nombre de paramètres décimaux.

Configuration de la classe publique: PersistantObject {

 public decimal temperature {get;set;}

 ...(times 20)

 public decimal gravity {get;set;}

}

Pour créer cet objet dans la couche de domaine plutôt que dans la couche du présentateur, il me faudrait passer chacune de ces valeurs décimales en tant que paramètres de fonction. Création d'une définition de fonction et d'un appel compliqués.

ie ConfigurationService.CreateConfiguration (temperature, ... (x20), gravité);

La meilleure solution serait peut-être de créer l'objet de configuration dans la couche du présentateur et d'affecter toutes les valeurs de l'objet de configuration directement à partir de l'entrée utilisateur, en ignorant un long appel de fonction.

Configuration config = ConfigurationFactory.CreateNewConfiguration ();

config.température = température;

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

config.gravity = gravité;

ConfigurationService.SaveNewConfiguration (config);

Mais je me demande si cette approche est fausse et pourquoi? Si ces deux approches sont erronées, quelle est la meilleure approche pour créer un objet de grande taille à partir des entrées de l'utilisateur et pourquoi?

Merci!

Answer 1

Je vous déconseille de laisser vos objets de domaine en dehors de la couche de domaine et dans la couche de présentation. Gardez la couche de présentation centrée sur la présentation.

Pour cette raison, je construis des objets de transfert de données afin de mélanger les données vers et depuis les couches de domaine et de présentation. Dans votre cas, demandez à la boîte de dialogue de renseigner un DTO transmis à votre service et traduit dans l'objet de domaine correspondant.

Cependant, vous ne voudriez pas construire des objets de domaine à partir de DTO. Envisager le cas où un DTO ne représente qu'un sous-ensemble d'un objet de domaine . Reconstruire un objet de domaine existant à partir d'un tel DTO vous donnerait un objet de domaine partiel. Vous voudrez probablement conserver un cache léger contenant l’objet de domaine complet pour pouvoir effectuer une mise à jour appropriée.

Pour résumer, vous obtiendriez la solution DTO si vous appliquiez le Introduire un objet de paramètre refactoring.

Answer 2

Il y a deux façons de gérer cela

1) Si ceci est configuré via un dialogue, je créerais des classes implémentant le modèle de commande et lierais un dialogue avec l'objet en question. Par exemple, CmdCreateConfigurationService et CmdEditConfigurationService.

CmdCreateConfigurationService s’appuierait sur une classe d’usine et sur les paramètres minimum nécessaires pour sélectionner le service de configuration approprié.

Vous configurez une interface IConfigurationServiceEditor et le transmettez en tant que paramètre parmi les paramètres à CmdEditConfiguration Parameters. Avec l'interface IConfigurationServiceEditor, vous définissez autant de méthodes que nécessaire pour faciliter le transfert d'informations depuis et vers la boîte de dialogue. Je recommande d'utiliser une collection de clés et de valeurs. L'objet de commande sait comment configurer le service de configuration à partir de cette collection. Le dialogue sait s’attendre à cette collection lors de la configuration.

Quelle que soit la structure de données, vous effectuerez le travail de configuration du service de configuration dans l'objet de commande. En implémentant IConfigurationServiceEditor, un objet non dialog / form / screen permet d'automatiser vos tests et, dans certaines circonstances, facilite la configuration d'objets complexes.

J'ai développé cette méthode pour un logiciel de CAO / FAO comportant plusieurs dizaines de formes paramétriques, chacune comportant de 4 à 40 entrées.