Méthode de fabrique avec du DI et du Cio

Je suis familier avec ces modèles, mais ne sais toujours pas comment gérer la situation suivante:

public class CarFactory
{
     public CarFactory(Dep1,Dep2,Dep3,Dep4,Dep5,Dep6)
     {
     }

     public ICar CreateCar(type)
     {
            switch(type)
            {
               case A:
                   return new Car1(Dep1,Dep2,Dep3);
               break;

               case B:
                   return new Car2(Dep4,Dep5,Dep6);
               break;
            }
     }
}

En général le problème est avec la quantité de références qui doit être injectée. Ce sera encore pire quand il y a plus de voitures.

Première approche qui me vient à l'esprit est d'injecter de Car1 et les personnages car2 dans l'usine du constructeur, mais il est contre l'approche parce que l'usine sera de retour toujours le même objet. La deuxième approche consiste à injecter servicelocator mais c'est antipattern partout. Comment le résoudre?

Edit:

Alternative 1:

public class CarFactory
{
     public CarFactory(IContainer container)
     {
        _container = container;
     }

     public ICar CreateCar(type)
     {
            switch(type)
            {
               case A:
                   return _container.Resolve<ICar1>();
               break;

               case B:
                     return _container.Resolve<ICar2>();
               break;
            }
     }
}

Alternative 2 (trop difficile à utiliser en raison d'un trop grand nombre de dépendances dans l'arbre):

public class CarFactory
{
     public CarFactory()
     {
     }

     public ICar CreateCar(type)
     {
            switch(type)
            {
               case A:
                   return new Car1(new Dep1(),new Dep2(new Dep683(),new Dep684()),....)
               break;

               case B:
                    return new Car2(new Dep4(),new Dep5(new Dep777(),new Dep684()),....)
               break;
            }
     }
}

Une pensée rapide est de faire un mappage de classe qui prend un type en entrée et retourne les trois Dep# vous avez besoin. Alors vous pouvez mapper toutes les dépendances, dans une instance de la cartographie de la classe dans le programme d'amorçage, puis injecter la cartographie de l'instance dans l'usine.
Je pense qu'il n'y a rien de mal avec Alternative way 1 que vous avez montré lors de la mise en œuvre de cette usine appartient à Composition Root. De ne pas vous inscrire DI conteneur lui-même dans le conteneur d'injection de dépendances
Que voulez-vous dire qu'il appartient à la Composition de la Racine? Pourriez-vous donner quelques exemples de code?
La Composition de la Racine est l'endroit où vous vous reliez votre demande de conteneur d'injection de dépendances. Ainsi, par exemple, cela peut être un Bootstrap classe.

InformationsquelleAutor MistyK | 2015-08-11

c#dependency-injection factory-pattern inversion-of-control

70

Avoir un commutateur cas énoncé à l'intérieur d'une usine est une odeur de code. Fait intéressant, vous ne semblez pas être en se concentrant sur la résolution de cette question à tous.

Le meilleur, le plus DI solution à l'amiable pour ce scénario est le modèle de stratégie. Il permet à votre DI conteneur à injecter les dépendances dans l'usine les cas où ils appartiennent, sans encombrer les autres classes avec ces dépendances ou de recourir à un service de localisation.

Interfaces
```
public interface ICarFactory
{
    ICar CreateCar();
    bool AppliesTo(Type type);
}

public interface ICarStrategy
{
    ICar CreateCar(Type type);
}
```
Usines
```
public class Car1Factory : ICarFactory
{
private readonly IDep1 dep1;
private readonly IDep2 dep2;
private readonly IDep3 dep3;
public Car1Factory(IDep1 dep1, IDep2 dep2, IDep3 dep3)
{
if (dep1 == null)
throw new ArgumentNullException("dep1");
if (dep2 == null)
throw new ArgumentNullException("dep2");
if (dep3 == null)
throw new ArgumentNullException("dep3");
this.dep1 = dep1;
this.dep2 = dep2;
this.dep3 = dep3;
}
public ICar CreateCar()
{
return new Car1(this.dep1, this.dep2, this.dep3);
}
public bool AppliesTo(Type type)
{
return typeof(Car1).Equals(type);
}
}
public class Car2Factory : ICarFactory
{
private readonly IDep4 dep4;
private readonly IDep5 dep5;
private readonly IDep6 dep6;
public Car1Factory(IDep4 dep4, IDep5 dep5, IDep6 dep6)
{
if (dep4 == null)
throw new ArgumentNullException("dep4");
if (dep5 == null)
throw new ArgumentNullException("dep5");
if (dep6 == null)
throw new ArgumentNullException("dep6");
this.dep4 = dep4;
this.dep5 = dep5;
this.dep6 = dep6;
}
public ICar CreateCar()
{
return new Car2(this.dep4, this.dep5, this.dep6);
}
public bool AppliesTo(Type type)
{
return typeof(Car2).Equals(type);
}
}
```
Stratégie
```
public class CarStrategy : ICarStrategy
{
private readonly ICarFactory[] carFactories;
public CarStrategy(ICarFactory[] carFactories)
{
if (carFactories == null)
throw new ArgumentNullException("carFactories");
this.carFactories = carFactories;
}
public ICar CreateCar(Type type)
{
var carFactory = this.carFactories
.FirstOrDefault(factory => factory.AppliesTo(type));
if (carFactory == null)
{
throw new Exception("type not registered");
}
return carFactory.CreateCar();
}
}
```
Utilisation
```
//I am showing this in code, but you would normally 
//do this with your DI container in your composition 
//root, and the instance would be created by injecting 
//it somewhere.
var strategy = new CarStrategy(new ICarFactory[] {
new Car1Factory(dep1, dep2, dep3),
new Car2Factory(dep4, dep5, dep6)
});
//And then once it is injected, you would simply do this.
//Note that you could use a magic string or some other 
//data type as the parameter if you prefer.
var car1 = strategy.CreateCar(typeof(Car1));
var car2 = strategy.CreateCar(typeof(Car2));
```
Notez que parce qu'il n'y a pas d'interrupteur instruction du cas, vous pouvez ajouter d'autres usines de la stratégie sans modification de la conception, et chacune de ces usines peuvent avoir leurs propres dépendances qui sont injectés par le conteneur d'injection de dépendances.
```
var strategy = new CarStrategy(new ICarFactory[] {
new Car1Factory(dep1, dep2, dep3),
new Car2Factory(dep4, dep5, dep6),
new Car3Factory(dep7, dep8, dep9)
});
var car1 = strategy.CreateCar(typeof(Car1));
var car2 = strategy.CreateCar(typeof(Car2));
var car3 = strategy.CreateCar(typeof(Car3));
```
- Wow, je ne pensais pas à ce sujet! Laisser l'usine de décider est une excellente idée. C'est mon préféré de réponse!
- Mais n'est-ce pas à l'aide de l'opérateur new considéré comme un no-go quand il s'agit de Cio? Pourrait les usines être mis en œuvre différemment (sans utiliser de nouveau et sans avoir recours au service locator modèle)?
- Quand il s'agit de la Coi, une utilisation de l'abstrait modèle de fabrique est pour abstacting la new opérateur sur le reste du code de l'isoler, le rendant DI sympathique. De ce fait, il faiblement couplés à partir du code qui utilise l'usine. Il n'est pas nécessaire que vous devez aller vers le conteneur pour résoudre l'instance - en fait, ce sera d'effectuer beaucoup plus rapide que d'utiliser le conteneur. Cela dit, l'injection du récipient dans l'abstract factory est une technique commune de permettre 3ème parties à intégrer à un cadre à l'aide de DI.
- Voir aussi Est-il un modèle pour l'initialisation des objets créés par l'intermédiaire d'un conteneur d'injection de dépendances et Pourquoi avons-nous besoin d'Abstract factory design pattern? pour plus d'informations sur l'utilisation de Résumé d'Usine en collaboration avec le DI.
- Je suis en train de travailler sur une solution similaire basé sur un enum. Lorsque vous avez une méthode Create(Type) j'ai Create(SomeEnum). La chose qui m'inquiète, c'est que cela semble à présent indésirables inconnus condition préalable lors de l'appel de Créer. Si j'ajoute un élément à la enum SomeEnum sans ajouter le correspondant de l'usine un client pourrait appeler Create(SomeEnum.SomeNewValue) et provoquer une exception de violation d'encapsulation comme indiqué ici blog.ploeh.dk/2015/10/26/service de localisation-viole-encapsulation
- Je ne recommanderais pas à l'aide d'un enum pour la stratégie de sélection. Pas seulement parce qu'il violait l'encapsulation, mais lorsque vous utilisez enum le code a changer dans 2 endroits différents lors de l'ajout d'un nouveau service de la stratégie. Si vous regardez à la mise en œuvre ci-dessus, à la fois de la logique sur la façon de sélectionner l'usine et la mise en œuvre de l'usine sont dans la même classe. Vous pouvez en ajouter ou en supprimer, sans changer aucune autre classe. Aussi, avec une légère modification, vous pourriez faire une stratégie d'exécuter plusieurs opérations à partir d'un ensemble beaucoup plus volumineux que dans cet exemple.
- Généralement, j'utilise de la chaîne comme type de données pour une stratégie. J'ai seulement utilisé System.Type dans cet exemple parce que c'est plus le long des lignes de ce que vous attendez lors de l'utilisation d'un localisateur de service et l'OP a eu le type de pratique à sélectionner avec. enum est un non-starter car il automatiquement traîne dans un indésirable type de la dépendance et la dépendance va dans les deux sens depuis l'enum est susceptible d'avoir des éléments qui ne sont pas inscrits auprès de la stratégie.
- Merci, je vois votre point de vue. J'avais choisi d'utiliser l'énumération que c'était une partie de la mise en œuvre de cette base de code que j'essaie de faire quelques refontes sur. On dirait que je devrait prendre un coup d'oeil à refactoring d'un moment antérieur. Besoin de mettre un peu plus de réflexion dans ce.
- Votre CarStrategy n'est pas vraiment une stratégie, mais une AbstractFactory. Et vous êtes de commutation/ramification par la FirstOrDefault méthode. La ramification de code dans une usine de n'est pas une odeur de code. Les instructions de branchement lors de la création d'objets sont la raison d'être de la Méthode de factorisation/Abstract Factory modèles.
- combine stratégie ET de l'usine. Résumé fatories permettre de produire des familles de classes, de ne pas décider lequel utiliser. Il transfère simplement l'appel à la injecté résumé de l'usine pour produire le bon type de l'élément.
- La stratégie est un modèle de comportement alors que l'Usine est un creational un. D'un pur point de vue de la mise en œuvre, ils ont la même apparence. Beaucoup de modèles sont une variation sur le même thème, le nom vient de la façon dont vous les utilisez. Étant donné que la CarStrategy crée un objet, c'est en fait une usine.
InformationsquelleAutor NightOwl888

Pour répondre à votre commentaire sur le code exemple avec Composition Root.
Vous pouvez créer suivantes et ce n'est pas un Service Locator.

public class CarFactory
{
private readonly Func<Type, ICar> carFactory;
public CarFactory(Func<Type, ICar> carFactory)
{
this.carFactory = carFactory;
}
public ICar CreateCar(Type carType)
{
return carFactory(carType);
}

et voilà comment regarder vos Composition Root à l'aide de l'Unité DI conteneur :

Func<Type, ICar> carFactoryFunc = type => (ICar)container.Resolve(type);
container.RegisterInstance<CarFactory>(new CarFactory(carFactoryFunc));

InformationsquelleAutor Arkadiusz K

2

J'ai répondu à une question similaire il y a quelques temps. Fondamentalement, il est tout au sujet de votre choix. Vous avez à choisir entre le niveau de verbosité (ce qui vous donne plus de l'aide d'un compilateur et de l'automatisation, qui permet d'écrire moins de code, mais c'est plus sujette aux bugs.

Cette est ma réponse soutenir le niveau de verbosité.

Et cette est également une bonne réponse qui prend en charge l'automatisation.

MODIFIER

Je crois que l'approche que vous envisagez de mal, c'est vraiment le meilleur. Vérité être dit, d'habitude il n'y aura pas donc nombreuses dépendances, là. J'aime cette approche parce que c'est très explicite et rarement des résultats des erreurs d'exécution.

Alternative 1:

Celui-ci est mauvais. C'est en fait un localisateur de service, qui est considéré comme un anti-modèle.

Alternative 2

Comme vous avez écrit, il n'est pas facile à utiliser si elle est mélangée avec du CIO containter. Toutefois, dans certains cas, une approche similaire (pauvre homme DI) peut être utile.

Dans l'ensemble, je n'aurais pas pris la peine de les avoir "beaucoup" de dépendances dans vos usines. C'est un simple déclarative code. Il faut quelques secondes pour écrire et peut vous épargner des heures de lutte avec des erreurs d'exécution.
- Votre solution semble être l'exemple de ma question, que je considère comme mauvais (en haut), suis-je droit?
- J'aime la plupart du temps mais il y a un problème avec elle. Ce qui se passe si Dep1 contient de l'état? Chaque fois que je créer de voiture-je obtenir de l'instance différente de la Voiture, mais la même Dep1 qui peuvent causer des problèmes.
- Comment sur la transmission Dep1Factory au lieu de Dep1?
- Il permettrait de résoudre ce problème. Je ne suis pas sûr de l'approche que je vais choisir mais je vous remercie pour l'aide 🙂
- content d'avoir pu aider 🙂
- la raison n ° 1 qui est mauvais n'est pas parce que c'est la SL comme il ne l'est pas. Ceci est un exemple parfait de la Usine Locale modèle (aka Solveur de Dépendances) qui n'ont pas le problème de la SL a - vous ne pouvez pas en abuser. La raison n ° 1 est mauvaise, c'est parce qu'elle introduit une non désirées et la mauvaise dépendance d'une infrastructure de classe à partir d'un domaine de classe.
- Pouvez-vous expliquer pourquoi il n'est pas un SL? Btw. J'aime bien votre mise en œuvre de l'Usine Locale. Je n'ai pas vu avant, mais il semble être utile dans certains cas. Prenez un plus 😉
- SL est un contrat qui permet de créer à peine quoi que ce soit sans contrôle. Celui-ci a un précise contrat qui permet la création du type très précis. Usine locale prend le Résumé de l'Usine comme un point de départ, mais au lieu de créer plusieurs des implémentations concrètes, vous avez juste un injectable fournisseur qui est configurable à partir de la Composition de la Racine.
- #1: "_container.Résoudre<ICar1>()" - cela ressemble exactement à "ouvrir un contrat qui permet de créer à peine quelque chose sans contrôle". Ne suis-je pas obtenir quelque chose?
- Je pense qu'il y a un malentendu. Quand on parle de Service Locator je faisais allusion à cette utilisation spécifique de la IContainer. Pas le CarFactory dans son ensemble.
- le conteneur n'est pas exposée à partir de l'usine. Aussi, l'usine ne vous permet pas de vous en faire un mauvais usage. Ainsi, il n'est pas le sl. La façon dont le conteneur est utilisé n'a pas d'importance. Une classe est un sl ou pas en raison de son contrat, la mise en œuvre.
- Oui, vous avez raison. Encore une fois, j'ai été pas faisant référence à la classe. Je n'aimais pas l'idée que l'usine utilise SL. Qui est essentiellement ce que vous avez écrit dans votre premier commentaire.
- il n'utilise pas le sl, il utilise le conteneur. À la suite de votre point ici, tous les recours possible à un récipient pourrait être appelé le sl. Et vous savez sûrement ce n'est pas le cas.
- Nope, pas de tous l'utilisation. À mon avis passer le récipient à l'extérieur de la composition de la racine est une SL.
- Je reçois votre point de vue et pourrait être d'accord. En passant nu conteneur à l'extérieur de CR est un antipattern. Je n'ai jamais appelé SL si.
InformationsquelleAutor Andrzej Gis

Je voudrais envisager de donner les dépendances d'une bonne structure, de sorte que vous pouvez utiliser quelque chose de similaire à Wiktor réponse, mais je voudrais résumé de la Voiture de l'usine elle-même. Ensuite, vous n'utilisez pas le cas..alors la structure.

public interface ICar
{
string Make { get; set; }
string ModelNumber { get; set; }
IBody Body { get; set; }
//IEngine Engine { get; set; }
//More aspects...etc.
}
public interface IBody
{
//IDoor DoorA { get; set; }
//IDoor DoorB { get; set; }
//etc
}
//Group the various specs
public interface IBodySpecs
{
//int NumberOfDoors { get; set; }
//int NumberOfWindows { get; set; }
//string Color { get; set; }
}
public interface ICarSpecs
{
IBodySpecs BodySpecs { get; set; }
//IEngineSpecs EngineSpecs { get; set; }
//etc.
}
public interface ICarFactory<TCar, TCarSpecs>
where TCar : ICar
where TCarSpecs : ICarSpecs
{
//Async cause everything non-trivial should be IMHO!
Task<TCar> CreateCar(TCarSpecs carSpecs);
//Instead of having dependencies ctor-injected or method-injected
//Now, you aren't dealing with complex overloads
IService1 Service1 { get; set; }
IBuilder1 Builder1 { get; set; }
}
public class BaseCar : ICar
{
public string Make { get; set; }
public string ModelNumber { get; set; }
public IBody Body { get; set; }
//public IEngine Engine { get; set; }
}
public class Van : BaseCar
{
public string VanStyle { get; set; } 
//etc.
}
public interface IVanSpecs : ICarSpecs
{
string VanStyle { get; set; }
}
public class VanFactory : ICarFactory<Van, IVanSpecs>
{
//Since you are talking of such a huge number of dependencies,
//it may behoove you to properly categorize if they are car or 
//car factory dependencies
//These are injected in the factory itself
public IBuilder1 Builder1 { get; set; }
public IService1 Service1 { get; set; }
public async Task<Van> CreateCar(IVanSpecs carSpecs)
{
var van = new Van()
{
//create the actual implementation here.
};
//await something or other
return van;
}
}

Je n'ai pas de liste, mais vous pouvez mettre en œuvre plusieurs types de voitures et des usines et l'utiliser DI pour injecter tout ce dont vous avez besoin.

Merci de lire mon commentaire à Viktor réponse. Dep1, Dep2.. ne sont pas des objets de données, qui sont des services, constructeurs, etc..
Dans mon interprétation de sa réponse, il dit simplement à créer un objet de paramètres (Specs dans mon exemple). Il n'a pas d'importance si elles sont des objets de valeur ou pas. Je pense que lui et moi sommes tous les deux en train de s'organiser dep1, dep2, etc, sans connaître les détails de ce que ces dépendances sont. La principale différence avec mon approche est que je ne serait pas seulement abstraction de ces params objets, je voudrais résumé les usines elles-mêmes, de sorte que vous pouvez utiliser DI pour eux au lieu de l'instruction switch à la fois de vous et de ses exemples.
J'ai ajouté où les services, les lecteurs, etc vous parliez de la irait. Ces sons de moins en moins de voiture de dépendances et de plus en plus de voiture de l'usine de dépendances.

InformationsquelleAutor

1

Tout d'abord, vous avez une usine de béton, un conteneur IoC pourrait être une alternative plutôt que quelque chose à vous y aider.

Ensuite, il suffit de refactoriser l'usine pour ne pas attendre à une possible liste des paramètres de l'usine du constructeur. C'est la principale question - pourquoi êtes-vous en passant donc de nombreux paramètres si la méthode n'a pas besoin d'eux?

Je préfère passer des paramètres spécifiques à la méthode de
```
public abstract class CarFactoryParams { }
public class Car1FactoryParams : CarFactoryParams
{
public Car1FactoryParams(Dep1, Dep2, Dep3) 
{ 
this.Dep1 = Dep1;
...
}
public class Car2FactoryParams 
...
public class CarFactory
{
public ICar CreateCar( CarFactoryParams params )
{
if ( params is Car1FactoryParams )
{
var cp = (Car1FactoryParams)params;
return new Car1( cp.Dep1, cp.Dep2, ... );
}
...
if ( params is ...
```
En encapsulant la liste des paramètres dans une classe spécifique, il suffit de rendre le client fournit exactement ces paramètres qui sont nécessaires pour les usines de l'invocation de méthode.

Edit:

Malheureusement, il n'était pas clair à partir de votre post, ce sont ces Dep1, ... et comment vous les utilisez.

Je suggère la démarche suivante puis qui sépare l'usine fournisseur de usine réelle mise en œuvre. Cette approche est connue sous le Usine Locale modèle:
```
public class CarFactory
{
private static Func<type, ICar> _provider;
public static void SetProvider( Func<type, ICar> provider )
{
_provider = provider;
}
public ICar CreateCar(type)
{
return _provider( type );
}
}
```
L'usine elle-même n'a pas toute la mise en œuvre, il est là pour poser les fondations de votre domaine d'API, où vous voulez que votre voiture instances être créés avec cette API uniquement.

Puis, dans la Composition de la Racine (quelque part près du point de départ de l'application, où vous configurez votre conteneur réel), vous pouvez configurer le fournisseur de:
```
CarFactory.SetProvider(
type =>
{
switch ( type )
{
case A:
return _container.Resolve<ICar1>();
case B:
return _container.Resolve<ICar2>();
..
}
);
```
Notez que dans cet exemple de mise en œuvre de l'usine du fournisseur utilise un délégué, mais une interface peut également être utilisé comme un cahier des charges d'un fournisseur réel.

Cette mise en œuvre est essentiellement #1 de votre édité question, cependant, il n'a pas tout particulier inconvénients. Le client appelle encore:
```
var car = new CarFactory().CreareCar( type );
```
- Ces dépendances sont des objets inscrits dans les CIO -> les services, les constructeurs, les lecteurs etc. pas des objets de valeur. CarFactoryParams sonne bien pour dataholder objets qui ne sont pas pour les dépendances qui en fait quelque chose. Je veux obtenir de conteneur est pourquoi j'ai voulu injecter avec le constructeur. Cio pourrait être utile de créer ces instances pour moi, en utilisant les dépendances déclarées dans le conteneur Ioc.
- édité ma réponse que vous a fourni plus de détails.
InformationsquelleAutor Wiktor Zychla
0

De nombreuses DI conteneurs de soutenir la notion de nommé dépendances.

E. g. (Structuremap syntaxe)
```
For<ICar>().Use<CarA>().Named("aCar");
Container.GetNamedInstance("aCar") //gives you a CarA instance
```
Si vous utilisez quelque chose comme une convention, une règle de la façon dont le nom est dérivé du béton du type de la voiture elle-même, vous avez une situation où vous n'avez pas besoin de toucher à l'usine plus lorsque vous étendez le système.

À l'aide de cette dans une usine est simple.
```
class Factory(IContainer c) {
public ICar GetCar(string name) {
Return c.GetNamedInstance(name);
}
}
```
- Je comprends votre point, mais il n'est pas exactement ce que je demande. En général, je ne pense pas que l'utilisation de IContainer dépendance est approprié à l'usine.Si c'est pour le problème est résolu, car il ne fait pas de différence si j'utilise nommé dépendances ou j'ai utiliser l'instruction switch à l'aide de Résoudre. Il résout le problème de la création d'interfaces pour tous résolus objet parce que quand je leur nom je peux me débarrasser d'eux. Mais le plus grand problème ici est IContainer comme la dépendance.
- Dans mon livre, les usines sont à peu près le seul endroit où j'avais permettre une dépendance directe sur le récipient, car ils sont généralement liés aux infrastructures.
- encore, vous pourriez avoir configurable interne fournisseur de l'usine qui peut être configuré à partir de la Composition de la Racine. De cette façon, l'usine seraient pas au courant d'une possible configuration lorsqu'un conteneur est utilisé. D'autre part, ayant le conteneur de dépendance dans votre usine du constructeur sonne comme un antipattern. Les usines sont une partie importante de l'API, leur mise en œuvre est généralement lié à l'infrastructure, l'API ne doit pas être, à mon humble avis.
InformationsquelleAutor flq

Vous devez vous connecter pour publier un commentaire.

Edit:

Interfaces

Usines

Stratégie

Utilisation

Edit: