¿Cómo debo ordenar mis parámetros ctor para DI / IOC?

Question

Soy un poco un novato DI, así que perdóname si este es el enfoque incorrecto o una pregunta tonta.

Digamos que tengo un formulario que crea / actualiza un pedido, y sé que necesitará recuperar una lista de productos y clientes para mostrar. Quiero pasar el objeto Order que está editando, pero también quiero inyectar ProductsService y CustomersService como dependencias.

Por lo tanto, querré que mi contenedor IoC (con el que vaya) proporcione los servicios, pero dependerá del código de llamada proporcionar el objeto Order para editar.

¿Debería declarar que el constructor toma el objeto Order como el primer parámetro y ProductsService y CustomersService después de eso, por ejemplo:

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

... o si las dependencias vienen primero y el objeto Order, por ejemplo:

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

¿Importa? ¿Depende de qué contenedor IoC utilizo? ¿O hay un " mejor " manera?

Answer 1

No estoy de acuerdo con la respuesta de @ aku.

Creo que lo que estás haciendo está bien y también hay otras formas de hacerlo que no son más o menos correctas. Por ejemplo, uno puede preguntarse si este objeto debería depender de los servicios en primer lugar.

Independientemente de la DI, creo que es útil aclarar en su mente al menos el tipo de estado que posee cada objeto, como el estado real (Orden), el estado derivado (si corresponde) y las dependencias (servicios):

http://tech.puredanger.com/2007/09/18/ spelunking /

En cualquier constructor o método, prefiero que los datos reales se pasen primero y que las dependencias o las cosas externas se pasen al final. Así que en tu ejemplo prefiero el primero.

Answer 2

Matt, no debes mezclar los parámetros normales con las dependencias. Dado que su objeto se creará en la parte interna del contenedor IoC, ¿cómo va a especificar los argumentos necesarios?

La combinación de dependencia y argumentos normales hará que la lógica de su programa sea más complicada.

En este caso, sería mejor declarar las propiedades de dependencia (es decir, eliminar dependencias del constructor) o inicializar el campo order después de que IoC construyera OrderForm y resolviera sus dependencias (es decir, eliminar parámetros normales del constructor).

También puede declarar todos sus parámetros, incluyendo orden como dependencias.

Answer 3

Me siento un poco incómodo al permitir que se instancia una instancia de OrderForm sin la referencia requerida a una instancia de Order. Una razón podría ser que esto me impediría hacer una verificación por adelantado de pedidos nulos. ¿Alguna otra idea?

Supongo que podría consolarme saber que los objetos OrderForm solo se instanciarán mediante un método Factory que garantiza que la propiedad Order se establezca después de realizar la llamada al marco de trabajo de IoC.