La séparation des préoccupations fournies par les cadres IOC / DI ne peut être surestimée pour un grand projet, mais existe-t-il une place pour de telles techniques dans un petit projet?
Pouvez-vous partager des utilisations réelles des cadres IOC / DI que vous avez trouvé utile lorsque vous codez un autre projet petit / moyen.
Par souci de définition:
Un "petit projet" contient 100-1000 lignes de code (Balpark, juste pour donner une idée), il faut 1-3 jours pour le code et la durée de vie de l'application résultante avant qu'il ne soit jetée ou à décompiration est à l'intérieur 1 semaine - 5 ans après la sortie initiale (ceci est là qu'il devient difficile de dessiner une ligne entre petit / moyen / grand projet).
Merci.
6 Réponses :
Pour un petit projet, je serais tenté d'utiliser encore une injection de dépendance, mais pas d'utiliser un cadre. Juste fabriquer toutes les dépendances de votre point d'entrée. Vous obtenez toujours tous les avantages de la testabilité et vous pouvez continuer à utiliser un conteneur à part entière plus tard - mais vous n'avez pas besoin de vous soucier de la configuration du conteneur jusqu'à ce qu'il ne soit utile.
J'ai utilisé cette approche sur deux petits projets et cela fonctionne très bien. Bien sûr, cela dépend de la complication de vos dépendances - qu'il soit nécessaire d'être des usines, de disposer de différentes caractéristiques, etc., etc., mais si c'est juste "j'ai ces trois choses qui dépendent tous d'un service d'authentification" alors c'est assez simple.
J'aime l'approche pragmatique - surtout lorsque le "petit projet" est souvent égal à un projet rapide que je ne pense pas grandir mais inévitablement "
mais y a-t-il une place pour de telles techniques dans un petit projet?
Même dans de petits projets, vous devez utiliser le motif de la COI afin d'affaiblir le couplage entre les couches et de le rendre testé unitaire. Toujours travailler avec des abstractions. Que vous utilisiez un cadre DI ou non n'a pas d'importance. Dans de petits projets, vous pouvez simplement faire la plomberie des dépendances manuellement, vous n'avez pas vraiment besoin d'un conteneur d'objet pour faire l'injection de dépendance, mais lorsque vous lui donnez une seconde pensée, pourquoi pas?
Quelle est votre réponse à propos de di conteneurs alors? Devrait-il utiliser des conteneurs di contenants ou pas?
@Robert Koritnik, personne ne peut donner une réponse objective à une telle question subjective. Je l'ai délibérément laissé ouvert.
+1 J'ai créé plusieurs cadres avant d'avoir acquis la connaissance cachée de la façon dont le CIO, DI fonctionne. L'échantillon meilleur, clair et clair pour moi est la mise en œuvre d'add-ins à l'aide de classes System.addin dans BCL dans .NET 4.0.
Je ne ferais pas la question de CIO à la taille du projet autant que:
Surtout les deux derniers rendront beaucoup plus facile si vous testez votre code pour lequel vous avez besoin (bien, il peut être évité avec des outils appropriés, mais ...) IOC.
Je suggérerais de ne pas utiliser de conteneurs di conteneurs pour commencer, mais De simples dépendances de deux niveaux sont facilement gérables manuellement sans utiliser de conteneurs di. Et probablement plus rapide à utiliser aussi. Cela rendra votre code facilement testable et en particulier de penser à cela si vous fournirez des bugs en tant que cas de test qui permettrait d'automatiser l'évitement de bugs futurs. petit Les projets présentant une valeur ajoutée dans l'environnement des entreprises ont tendance à être prolongés assez souvent car il pousse l'imagination de l'utilisateur à quel point les choses pourraient être améliorées encore plus. Alors ne sous-estimez pas votre projet petit . Il peut bientôt grandir. petit projet tend à croître
J'écris beaucoup de projets de tailles similaires, 30-40 par an.
J'utilise di mais crée ma propre classe d'usine avec une méthode de résolution. P>
public T Resolve<T>()
where T:class {
if (typeof(T).IsAssignableFrom(typeof(Something)))
return new Something(Resolve<ISomethingElse>()) as T;
...
}
dépend de ce que vous jugez important dans votre mise en œuvre. Si la qualification est importante et si vous avez tendance à suivre le principe de responsabilité unique (dans de petits ou grands projets), vous vous retrouvez généralement avec un peu plus de classes que vous auriez probablement autrement. Cela peut entraîner une invocation comme si vous pouvez vivre avec cela et personnellement, je le ferais aussi, dans une application de jeton, puis par tous signifie que vous n'avez pas vraiment besoin d'un conteneur DI. Allez avec tout ce qui vous rend heureux. Acclamations. EDIT : Au fil des ans J'ai trouvé Tinyioc comme un bon compromis pour des projets plus petits.
En règle générale, pourquoi ne pas utiliser un conteneur di conteneur pour de petits projets? Plus votre base de code, plus simple, il est d'utiliser un conteneur, mon conseil est utilisé sur celui qui fournit une interface de fluide simple pour l'enregistrement de la dépendance ou utilisez simplement Linq, puis vous finissez avec une très petite empreinte qui file de votre Application complète:
public void OnStartup(args){
var container = new IoCContainerOfChoice();
Types.FromThisAssembly()
.ForEach(type => container.Register(type, type.DefaultInterface());
container.Resolve<ShellView>();
}