84 votes

Pourquoi ne pas utiliser un conteneur IoC pour résoudre les dépendances d'entités / objets métier?

Je comprends le concept derrière DI, mais je suis en train d'apprendre quels sont les différents conteneurs IoC peut faire. Il semble que la plupart des personnes recommandent à l'aide du Cio conteneurs fil des apatrides services, mais qu'en les utilisant pour la dynamique des objets comme des entités?

Si c'est bon ou mauvais, normalement, je stuff mon entités de comportement, même si ce comportement implique un en dehors de la classe. Exemple:

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);
    }
}

Comme vous pouvez le voir, les dépendances sont Constructeur Injecté. Maintenant, pour un couple de questions.

  1. Est-il considéré comme une mauvaise pratique d'avoir votre entités dépendent de l'extérieur des classes comme le ShipQuoter? L'élimination de ces dépendances semble me conduire vers une anémie de domaine, si je comprends correctement la définition.

  2. C'est une mauvaise pratique d'utiliser un conteneur IoC pour résoudre ces dépendances et de construction d'une entité lorsque nécessaire? Est-il possible de faire cela?

Merci pour toute la perspicacité.

93voto

Mark Seemann Points 102767

La première question est la plus difficile à répondre. Est-ce un mal d'avoir des Entités dépendent en dehors des cours? C'est certainement pas le plus fréquent.

Si, par exemple, vous pouvez injecter un Dépôt dans votre Entités, vous pouvez effectivement avoir une implémentation du modèle d'Enregistrement Active. Certaines personnes comme ce modèle pour le confort, tandis que d'autres (comme moi) considèrent que c'est une odeur de code ou anti-modèle, car elle viole le Principe de Responsabilité Unique (SRP).

On pourrait dire que l'injection de dépendances dans les Entités de vous tirer dans la même direction (à l'écart de SRP). D'autre part, vous êtes certainement corriger que si vous ne le faites pas, le pull est vers une Anémique Modèle de Domaine.

J'ai du mal avec tout cela pendant un long moment jusqu'à ce que je tombe sur Greg Young (abandonné) de papier sur DDDD où il explique pourquoi le stéréotype n-tier/n-couche de l'architecture sera toujours CRUDy (et donc plutôt anémique).

En déplaçant notre attention sur la modélisation des objets du Domaine, comme les Commandes et les Événements au lieu des Noms semble nous permettre de construire une bonne orientée objet, modèle de domaine.

La deuxième question est plus facile de répondre. Vous pouvez toujours utiliser un Résumé de l'Usine pour créer des instances au moment de l'exécution. Avec le Château de Windsor, vous pouvez même utiliser le Tapé de l'Usine de Facilité, vous soulager de la charge de la mise en œuvre de la usines manuellement.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X