Comment dois-je commander mes paramètres ctor pour DI / IOC?

Question

Je suis un peu un débutant en DI, alors pardonnez-moi s'il s'agit d'une mauvaise approche ou d'une question idiote.

Supposons que j'ai un formulaire qui crée / met à jour une commande et que je sais qu'il va falloir récupérer une liste de produits et de clients à afficher. Je souhaite transmettre l'objet Order qu'il est en train de modifier, mais je souhaite également injecter ProductsService et CustomersService en tant que dépendances.

Je souhaite donc que mon conteneur IoC (quel que soit celui avec lequel je vais) fournisse les services, mais ce sera au code de l'appelant de fournir l'objet Commande à modifier.

Dois-je déclarer le constructeur en prenant l'objet Order en tant que premier paramètre, puis ProductsService et CustomersService, par exemple:

public OrderForm(Order order, ProductsService prodsSvc, CustomersService custsSvc)

... ou les dépendances doivent-elles figurer en premier et l'objet Commande en dernier, par exemple:

public OrderForm(ProductsService prodsSvc, CustomersService custsSvc, Order order)

Est-ce important? Cela dépend-il du conteneur IoC que j'utilise? Ou y a-t-il un "meilleur" chemin?

Answer 1

Je ne suis pas d'accord avec la réponse de @ aku.

Je pense que ce que vous faites est bien et qu'il existe également d'autres façons de le faire qui ne sont ni plus ni moins correctes. Par exemple, on peut se demander si cet objet devrait dépendre des services en premier lieu.

Indépendamment de DI, j'estime utile de préciser au moins le type d'état de chaque objet, tel que l'état réel (Ordre), l'état dérivé (le cas échéant) et les dépendances (services):

http://tech.puredanger.com/2007/09/18/ spéléologie /

Sur tout constructeur ou méthode, je préfère que les vraies données soient passées en premier et les dépendances ou les éléments externes en dernier. Donc, dans votre exemple, je préférerais le premier.

Answer 2

Matt, vous ne devriez pas mélanger les paramètres normaux avec les dépendances. Puisque votre objet sera créé dans les composants internes du conteneur IoC, comment allez-vous spécifier les arguments nécessaires?

Le mélange des dépendances et des arguments normaux compliquera la logique de votre programme.

Dans ce cas, il serait préférable de déclarer les propriétés de dépendance (c'est-à-dire supprimer les dépendances du constructeur) ou d'initialiser le champ order après que IoC a construit OrderForm et résolu ses dépendances (c'est-à-dire paramètres normaux du constructeur).

Vous pouvez également déclarer tous vos paramètres, y compris order , en tant que dépendances.

Answer 3

Je suis un peu mal à l'aise d'autoriser l'instanciation d'une instance de OrderForm sans la référence requise à une instance de Order. Une des raisons pourrait être que cela m'empêcherait de procéder à une vérification initiale des ordres nuls. Avez-vous d'autres idées?

Je suppose que je pourrais être rassuré de savoir que les objets OrderForm ne seront instanciés que par une méthode Factory assurant que la propriété Order est définie après l'appel à l'infrastructure IoC.