dependency-injection - type - unity di container

¿Por qué no usar un contenedor IoC para resolver dependencias para entidades/objetos comerciales?

Question

Entiendo el concepto detrás de DI, pero estoy aprendiendo qué pueden hacer diferentes contenedores de IoC. Parece que la mayoría de las personas aboga por el uso de contenedores IoC para conectar servicios apátridas, pero ¿qué hay de usarlos para objetos con estado como entidades?

Ya sea correcto o incorrecto, normalmente relleno mis entidades con el comportamiento, incluso si ese comportamiento requiere una clase externa. Ejemplo:

public class Order : IOrder
{
private string _ShipAddress;
private IShipQuoter _ShipQuoter;
public Order(IOrderData OrderData, IShipQuoter ShipQuoter)
{
// OrderData comes from a repository and has the data needed
// to construct order
_ShipAddress = OrderData.ShipAddress; // etc.
_ShipQuoter = ShipQuoter;
}
private decimal GetShippingRate()
{
return _ShipQuoter.GetRate(this);
}
}

Como puede ver, las dependencias son Constructor Inyectado. Ahora por un par de preguntas.

1. ¿Se considera una mala práctica que sus entidades dependan de clases externas como ShipQuoter? La eliminación de estas dependencias parece llevarme hacia un dominio anémico, si entiendo la definición correctamente.

2. ¿Es una mala práctica usar un contenedor IoC para resolver estas dependencias y construir una entidad cuando sea necesario? ¿Es posible hacer esto?

Gracias por cualquier idea.

Answer 1

La primera pregunta es la más difícil de responder. ¿Es una mala práctica que las entidades dependan de clases externas? Ciertamente no es lo más común de hacer.

Si, por ejemplo, usted inyecta un Repositorio en sus Entidades, efectivamente tiene una implementación del patrón de Registro Activo . A algunas personas les gusta este patrón por la comodidad que brinda, mientras que otros (como yo) lo consideran un código oloroso o antipatrón porque viola el Principio de Responsabilidad Individual (SRP).

Podría argumentar que inyectar otras dependencias en Entidades lo llevaría en la misma dirección (lejos de SRP). Por otro lado, sin duda tiene razón en que, si no lo hace, la atracción se dirige hacia un Modelo de Dominio Anémico .

Luché con todo esto durante mucho tiempo hasta que encontré el artículo de Greg Young (abandonado) sobre DDDD donde explica por qué la arquitectura estereotípica n-tier / n-layer siempre será CRUDy (y por lo tanto bastante anémica).

Al mover nuestro enfoque al modelado de objetos de dominio como comandos y eventos en lugar de sustantivos, parece que nos permite construir un modelo de dominio orientado a objetos adecuado.

La segunda pregunta es más fácil de responder. Siempre puede usar Abstract Factory para crear instancias en tiempo de ejecución . Con Castle Windsor, incluso puede utilizar Typed Factory Facility, lo que le ahorra la carga de implementar las fábricas de forma manual.

Answer 2

Sé que esta es una publicación anterior, pero quería agregarla. La entidad de dominio no debe persistir incluso si pasa en un repositorio abstraído en ctor. El motivo por el cual sugiero que esto no es meramente que viola el SRP, sino que también es contrario a la agregación de DDD. Permítanme explicar, DDD es adecuado para aplicaciones complejas con gráficos inherentemente profundos, por lo tanto, utilizamos raíces compuestas o agregadas para persistir en los cambios a los "hijos" subyacentes, de modo que cuando inyectamos persistencia en los niños individuales violamos la relación que los niños tienen con el raíz compuesta o agregada que debería estar "a cargo" del ciclo de vida o agregación. Por supuesto, la raíz compuesta o el agregado tampoco persisten en su propio gráfico. Otra es que al inyectar dependencias de objetos DDD, un objeto de dominio inyectado no tiene ningún estado hasta que se produce otro evento para hidratar su estado. CUALQUIER consumidor del código se verá obligado a iniciar o configurar el objeto de dominio primero antes de que pueda invocar un comportamiento comercial que viole la encapsulación.