IoC et ASP.NET MVC, où cela commence-t-il ?

Question

Je vois "IoC" et "DI" mentionnés presque partout pour ASP.NET MVC. Bien que je sois bien conscient de ... de ce que c'est, c'est un de ces concepts flottants presque ambigus et amorphes qui semble m'avoir échappé, ou alors je ne regarde pas au bon endroit. Avec la sortie prochaine de ASP.NET MVC 3.0, je le vois encore plus. À tel point que j'ai l'impression qu'il s'agit d'une partie entière de la programmation que je n'ai fait qu'effleurer. ne savent pas .

J'ai essayé de chercher des livres sur le sujet, mais la plupart de ce que je trouve semble faire beaucoup d'hypothèses (histoire de Ruby, comprendre ce que c'est mais pas comment l'utiliser, etc).

Je pose simplement la question de manière franche et directe. Qu'est-ce que c'est ? est IoC, et pourquoi m'en préoccuper ? Existe-t-il des sites web décents qui couvrent ce sujet du point de vue d'un programmeur débutant ? Supposons que je n'y connaisse rien. Supposons que je ne connaisse rien d'autre que le C#. J'ai lu tous les livres, blogs et tutoriels sur le C# de .NET 1.1 à .NET 2.0, et lorsque .NET 3.5 et LINQ sont apparus, je n'arrivais plus à suivre. Je suis un développeur débutant qui travaille en ASP.NET MVC/C# et je ne peux m'empêcher de penser qu'il me manque quelque chose de très important. (J'ai les mêmes sentiments à propos de l'injection de dépendances (DI)).

J'ai cherché sur Google, j'ai lu des blogs, j'ai vu Castle.Windsor J'ai vu des exemples de code, j'ai parcouru des livres et des webcasts, et je suis toujours dans le noir. C'est comme une de ces histoires internes au travail que vous savez que vous devriez connaître, mais pour une raison quelconque, vous ne le savez pas, et l'école ne m'a pas vraiment préparé à cela.

Pour moi, StackOverflow a toujours été la meilleure des meilleures communautés de développement. Grâce à l'université, au travail d'initiation et au travail indépendant de bas niveau, j'ai amalgamé mon éducation à la programmation auprès d'autres programmeurs (bien que, d'après ce que je comprends, ce n'est pas nécessairement quelque chose dont il faut avoir honte). Une fois de plus, je m'adresse donc simplement à la communauté.

Hein ? Je ne comprends pas.

En parlant avec beaucoup de mes collègues qui essaient de percer dans le même domaine, beaucoup d'entre eux ressentent la même chose. Je ne peux donc pas m'empêcher de penser que, quelque part, nous, les programmeurs "débutants", avons manqué le mémo de ces approches conceptuelles du codage. J'aimerais non seulement obtenir une réponse à cette question, mais je pense qu'un bon fil de discussion pour d'autres personnes comme moi qui essaient de comprendre serait une idée intelligente (et s'il en existe un, il faut le rendre plus évident).

Voici quelques-unes des choses que j'ai trouvées et qui m'ont été utiles http://www.theserverside.com/news/1321158/A-beginners-guide-to-Dependency-Injection y http://www.dotnetspark.com/kb/1222-inversion-control--beginner-guide.aspx

Mais je reste perplexe sur un certain nombre de points quant à l'importance de cette démarche. En vérité, j'ai l'impression qu'une grande partie de la communauté des développeurs ressent la même chose à propos de l'IoC et des tests unitaires. Très peu de choses sont exposées ce que et les exemples découverts sont généralement assez pauvres ou très difficiles à comprendre. Lorsque .NET a été introduit, il était autonome. Je n'avais pas besoin d'un tas d'autres concepts pour faire fonctionner des programmes simples. Aujourd'hui, .NET est un langage respecté et tout le monde l'adopte (nHibernate, MVC, MVP, MVVP, plateformes de clouding, architecture de jeux, etc.)

(N'hésitez pas à me signaler si je me trompe de manière flagrante. Je ne me qualifie pas de "bon", loin de là. Mais je connais le langage C#, et je le connais très bien. Je me considère comme quelqu'un qui apprend très vite et si j'ai autant de mal avec ça, je dois supposer qu'il y a un "trou" à combler).

Answer 1

Laissons de côté tous les cadres IoC et discutons du concept. IoC n'est pas un nouveau concept et existe depuis longtemps. L'IoC est fondamentalement mis en œuvre pour rendre votre système faiblement couplé à certains sous-systèmes. Nous réalisons le découplage en extrayant le comportement commun/de base du sous-système dans un contrat. Le contrat se présente généralement sous la forme d'une interface. Vous dépendez maintenant de cette interface. Vous ne vous souciez pas de savoir comment un système particulier vous donne concrètement le comportement que vous recherchez.

Récemment, j'ai été confronté à ce problème dans ma vie réelle. Nous disposons d'un système de paiement existant et nous développons un nouveau système de paiement pour adhérer à la norme PCI. Ce qu'il faut faire dans ce genre de situation, c'est extraire les caractéristiques communes des deux systèmes dans une interface, puis votre application interagit avec ces deux systèmes uniquement via l'interface. Vous pouvez soit utiliser un drapeau dans le fichier de configuration, soit un modèle d'usine, soit enfin un cadre IoC pour injecter cette dépendance dans votre application. Au moment de l'exécution, votre application obtiendra l'objet dont elle dépend. Vous avez besoin de DI/IoC dans un environnement où l'incertitude règne quant à l'utilisation d'un sous-système donné, quelle qu'en soit la raison. Dans cet exemple, le nouveau système de paiement n'a pas pu être livré à temps et mon application avait donc besoin d'une option configurable pour passer d'un système à l'autre au moment de l'exécution. Si je ne fais pas de IoC, je devrai modifier le code à chaque fois que l'entreprise changera d'avis.

Un autre besoin de l'IoC est de faire du TDD. La même chose que ce que j'ai décrit ci-dessus peut être utilisée pour développer une implémentation fictive de l'application réelle et peut être utilisée pour faire des tests pendant que le composant réel est encore en cours de développement.

Injection de dépendance est un bon livre pour commencer. Vous pouvez également télécharger un document gratuit du même auteur sur le bricolage. ici .

Mise à jour : ajout d'un code pour plus de clarté

public interface ITest
    {
        void Hello();
    }

Je peux maintenant avoir deux implémentations concrètes différentes :

public class Hi : ITest
    {
        public void Hello()
        {
            HttpContext.Current.Response.Write("Hi there!");
        }
    }

    public class HelloMessage : ITest
    {
        public void Hello()
        {
            HttpContext.Current.Response.Write("Hello there!");
        }
    }

ITest messenger;

if (User Needs "Hi")
{
   messenger = new Hi();
}
else if (User Needs "Hello")
{
   messenger = new HelloMessage();
}

messenger.Hello(); 

Tout ce que mon application doit faire, c'est appeler la méthode disponible dans le contrat. À l'heure actuelle, l'application gère les dépendances de manière explicite, mais elle est libre de toute implémentation concrète. Cependant, elle est toujours liée à ces deux implémentations concrètes. Les cadres IoC nous aident à externaliser ce travail dans un fichier de configuration. Je peux y fournir n'importe quelle autre implémentation concrète, indépendamment de la manière dont elle est mise en œuvre, et l'application continuera à fonctionner sans aucune modification du code.

Voici le code dans lequel j'utilise Unity 2 et j'externalise moi-même la gestion explicite des dépendances.

using (IUnityContainer container = new UnityContainer())
            {
                container.LoadConfiguration();

                ITest messenger = container.Resolve<ITest>();

                messenger.Hello();
            }

Config pour la même chose :

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
  <assembly name="Injection"/>
  <container>
    <register type="Injection.ITest" mapTo="Injection.Hi"/>
  </container>
</unity>

HTH

Answer 2

Pour des vidéos d'introduction, voir DimeCasts.net .

Les deux principales raisons pour lesquelles j'aime la COI :

1. Tests unitaires plus faciles.
2. Il est plus facile d'échanger les données du backend pour les tester. Supposons que vous ayez un référentiel de personnes (IPersonRepository). Votre code implémente un PersonRepository qui charge les données depuis la base de données. Mais que se passe-t-il si vous n'avez pas de données dans la base de données ou si la base de données n'est pas encore configurée ? Vous utilisez IoC pour implémenter un DummyPersonRepository qui chargera les données depuis un autre endroit, comme un fichier XML ou des données codées en dur.

Answer 3

Consultez la vidéo gratuite "Dependency Injection and Inversion of Control" (Injection de dépendances et inversion de contrôle) à l'adresse suivante http://tekpub.com/channels/free

Answer 4

Je pense que vous commencerez à comprendre l'IoC/DI lorsque vous comprendrez pourquoi et quand il est utilisé. Je ne m'inquiéterais pas trop de savoir quel conteneur IoC utiliser. Vous pouvez essentiellement écrire un conteneur de base vous-même (au niveau le plus basique, il s'agit simplement d'un dictionnaire qui fait correspondre une interface à une implémentation concrète). Aquí est une bonne vidéo qui montre comment procéder.

Le concept de base est qu'il encourage le couplage lâche des composants, ce qui signifie que le code est plus facile à tester et ne dépend pas d'autres classes concrètes.

Ce lien contient des détails sur les principes SOLID, votre question concerne plus particulièrement le "D" (Dependency Inversion Principle), mais les autres principes seront également intéressants.

Answer 5

J'ai posé une question similaire il y a quelque temps, et j'ai reçu des réponses intéressantes à l'adresse suivante http://stackoverflow.com/questions/770039/examples-of-ioc-containers