Castle Windsor Y a-t-il des inconvénients?

Question

J'ai été à la recherche dans le château de projet et plus particulièrement de windsor. J'ai été tellement impressionné par ce qu'il est possible avec cette technologie et les avantages d'un tel système faiblement couplé sont certainement apparent. La seule chose que je suis pas sûr de l'est si l'utilisation de cette méthode a des inconvénients, plus précisément dans asp.net?? par exemple, les performances etc.

Je suis en train de faire les avantages de cette approche visible par mes collègues développeurs ici et je suis frappé par le suivant retours:

1) C'est à l'aide de la réflexion et à chaque fois qu'un objet est appelée à partir du conteneur, la réflexion doit être utilisé de sorte que les performances seront terribles. (Est-ce le cas? faut-il utiliser la réflexion à chaque appel?)

2) Si je me base sur les Interfaces comment dois-je traiter avec des objets qui ont plus de propriétés et des méthodes qui ont été ajoutés à la fin de la classe? (par héritage)

Answer 1

Pour répondre à vos questions:

1) C'est à l'aide de la réflexion et de chaque le temps qu'une abjecte est appelé à partir de la conteneur, la réflexion doit être utilisé de sorte la performance sera terrible. (Est-ce le cas? faut-il utiliser la réflexion sur chaque appel?)

• non, il ne fonctionne pas. La plupart du temps, il utilise peu de réflexion lorsque vous vous inscrivez le composant. Il peut également utiliser la réflexion, tout en générant de type de proxy, la première fois que vous demandez un composant du contenant

2) Si je me base sur les Interfaces comment dois-je traiter avec des objets qui ont plus de des méthodes et des propriétés qui ont été cloué sur la classe? (par le biais de l'héritage)

• tout est une question de conception. Vous ne voulez pas avoir à chaque objet créé par le conteneur. Vous l'utiliser principalement pour les dépendances de service. Dans ce cas, vous ne se soucient pas de ce type est en fait de se cacher derrière l'interface (c'est le but de tout cela, n'est-ce pas?).

Vous pouvez aussi avoir des composants de classe, mais ils ont des limites, et vous devez être conscient de ces derniers (par exemple, vous ne pouvez pas intercepter les appels à la non-méthodes virtuelles). J'ai trouvé Windsor pour être la plus mature, et la mieux adaptée à mon style de développement conteneur de tous.

Autre que cela. Les performances. Je n'ai pas entendu parler d'un projet qui a dû rejeter la dépendance conteneur en raison de performances inacceptable. Windsor est vraiment intelligente, et il met en cache les résultats des opérations de longue durée, de sorte que vous n'avez pas à payer le prix deux fois. Vous pouvez trouver des cartes sur Internet, la comparaison de la vitesse de nombreux Cio conteneurs. Deux choses à noter à propos de ces: Tous les conteneurs sont vraiment rapide. Ne pense pas que le fait que d'autres conteneurs sont plus rapides sur ces graphiques que Windsor, signifie qu'ils sont mieux. Windsor fait beaucoup de choses pour vous que d'autres contenants ne le font pas.

Answer 2

J'ai utilisé du Cio conteneurs (Spring.NET et StructureMap) dans la production de plusieurs applications sous forte charge (pas de Facebook ou de MySpace haut, mais assez pour du stress un peu de serveurs).

Dans mon expérience, avant même que j'ai commencé à utiliser du Cio, la plus grande perf préoccupation est la base de données et l'interaction avec la base de données, optimisation des requêtes, des index, à l'aide de 2ème niveau de la mise en cache, etc.

Si vous avez une base de données de votre application, quelle que soit la performance de Windsor ou tout autre récipient peut causer sera donc infintessimally petit par rapport à un DB aller-retour.

C'est comme les gens qui comparent les performances de la nouvelle() opérateur contre l'Activateur.CreateInstance() à 1-10ms quand un seul DB aller-retour est généralement un ordre de grandeur plus cher.

Je vous conseille de ne pas se soucier des petites choses et se concentrer sur les gros trucs.

Aussi, je tiens à vous informer de regarder StructureMap, comme je crois qu'il a beaucoup plus de fonctionnalités qu'Windsor et n'ont pas beaucoup de Windsor défauts (c'est à dire en tenant références et vous obligeant à les libérer, etc).

Answer 3

Un problème avec le Château de Windsor, je suis tombé sur qu'il n'est pas en mesure d'exécuter dans un niveau de Confiance Moyen (sans recompilation dont je n'étais pas capable de faire). J'ai donc besoin de passer de Windsor à l'Unité.

Selon DI/Cio performances - je crois que le gain de performance n'est pas grande, surtout lorsque vous gardez à l'esprit le pouvoir qu'elle possède.

BTW: Si vous êtes en début de DI/Cio, vous devriez lire cet article MSDN.

Answer 4

D'importants coûts de démarrage, presque pas de gain de performance pendant le fonctionnement (pas de réflexion pour les appels, bien sûr - tout est compilé lors de l'instanciation). Windsor est un peu sur un côté lourd, mais avec une bonne gestion de durée de vie ne devrait pas causer de problèmes.

Plus important inconvénient est que les problèmes d'intégration ne sont pas pris lors de la construction, et certains même pas au lancement. Sans attention au suivi de tous les modules des versions et des essais en continu de l'ensemble du système, il est facile de se mettre dans le pétrin. Réflexion permet, ici, de sorte que Windsor est mieux dans cet aspect que beaucoup d'autres DI cadres.

Answer 5

La seule exception du cas où la performance d'un conteneur IoC est inacceptable dans mon expérience, c'est lorsqu'on essaie d'intégrer et d'envelopper le conteneur IoC comme un IServiceProvider pour une utilisation dans le ComponentModel - une fois un exemple courant de cet été lors de la création de votre propre hébergé winforms designer (normalement de construire une sorte de concepteur personnalisé, c'est à dire de workflow/organigramme etc.)

En raison de la façon dont un certain nombre de winforms composants se comportent, en particulier au moment de la conception, le coût de la résolution d'un composant physiquement provoquer la souris pour "stutter" lorsque vous faites glisser, parce que le cadre peut faire plus de 30 000 service de la résolution appelle un deuxième - c'est plus une réflexion sur les mauvaises pratiques de codage dans les composants eux-mêmes bien que je pense, ou au moins en raison des hypothèses formulées au sujet de l'prestataires de services de mise en œuvre rapide/simple.

Dans la pratique, je n'ai jamais trouvé la composante temps de résolution d'un problème, même lourdement chargé applications commerciales.