2009-08-11 9 views
1

Je construis des sites Web avec ASP.NET depuis un moment déjà. Au début, j'ai évité d'apprendre les subtilités du modèle ASP.NET Provider. Au lieu de cela, j'ai utilisé les fournisseurs de boîtes de conserve si nécessaire, et je me suis largement appuyé sur les frameworks d'injection de dépendances pour tous mes autres besoins. Récemment, cependant, j'ai écrit des composants enfichables pour ASP.NET et bien sûr écrit de nombreuses solutions personnalisées basées sur les fournisseurs pour y arriver. Il est devenu rapidement évident pour moi cependant, que beaucoup de initialization code is being duplicated, ce qui est une mauvaise chose.Fournisseurs personnalisés, meilleures pratiques et conflits de configuration

Alors ...

  1. Y at-il des meilleures pratiques qui ont émergé sur la façon d'éviter le code spaghetti de configuration?
  2. Avez-vous construit, ou avez-vous des exemples (classes de base/auxiliaires, attributs personnalisés, réflexion) à partager pour extraire le code d'initialisation de base afin de créer des fournisseurs personnalisés est plus facile?

REMARQUE:

S'il vous plaît ne pas essayer de me envoyer sur le site Provider Toolkit. J'ai déjà épuisé cette ressource, c'est pourquoi je me tourne vers la communauté SO :)

+1

Je voudrais offrir de l'aide, mais je ne suis pas vraiment clair sur quelque chose. Vous écrivez des "composants enfichables" pour ASP.NET, et "bien sûr" écrivez beaucoup de solutions personnalisées basées sur les fournisseurs ... Je ne suis pas sûr exactement ce que vous entendez par composant enfichable, ou pourquoi il est évident que vous écrivez différents fournisseurs pour chaque composant. Pourriez-vous clarifier ce que vous essayez de faire, et pourquoi vous avez besoin d'un fournisseur différent pour chaque composant? Je verrai si je peux offrir de l'aide. – jrista

+0

Avez-vous vu ELMAH? Je me suis efforcé d'écrire des composants qui sont transversaux dans leurs préoccupations, mais pas domaine/application spécifique. Modules, gestionnaires, etc ... Si elles touchent n'importe quel type de stockage, ils doivent utiliser le modèle du fournisseur pour être vraiment connectable (machine.config/web.config). Ce n'est pas un problème, mais je remarque que vous finissez par écrire beaucoup de code pour simplement gérer les trucs de configuration. Je me demandais juste si quelqu'un avait fait cela assez pour trouver des meilleures pratiques, ou même des méthodes d'utilité pour la manipulation générique de ce type de code de plomberie. – Josh

+0

C'est comme le double schéma de verrouillage pour la mise en cache dans un environnement Web.Si vous faites quelque chose avec le cache, vous finissez par écrire ce code, mais vous le factorisez généralement dans une classe d'utilitaires pour faire le gros du travail, donc vous n'avez pas besoin de l'écrire deux fois. Il y a beaucoup de choses que vous finissez par faire lors de la gestion des sections de configuration, et je me demandais simplement si des schémas avaient émergé spécifiquement pour ce problème. Je veux juste être aussi DRY que possible. – Josh

Répondre

0

Je viens de faire une implémentation approximative de l'implémentation plutôt basique des fournisseurs d'appartenance et de rôle, et je n'ai pas de duplication de code à tout!

J'ai divisé tout en trois projets (plus des tests):

  • application - asp.net application mvc. modèles, contrôleurs, etc.
  • Infrastructure - Interfaces et IoC
  • Infrastructure.Web - Fournisseurs

Le modèle pour l'utilisateur et le rôle implémentent des interfaces de l'infrastructure et les classes se faire enregistrer à l'IoC au démarrage de l'application. Les fournisseurs demandent ensuite à l'IoC de résoudre les classes et le fait. De cette façon, je peux ajouter des choses au modèle et à l'interface utilisateur en utilisant les mêmes fournisseurs. Le seul problème que j'ai remarqué, c'est que le Web lancé par le bouton "Configuration ASP.NET" ne peut pas utiliser les fournisseurs, car l'installation est en cours dans Application_Start et la "Configuration ASP.NET" est un autre web . Je ne vois pas cela comme un problème cependant.

+0

J'essaie spécifiquement de construire des composants enfichables qui peuvent être déposés dans n'importe quel projet ASP.Net. J'AIMERAIS utiliser un IoC, mais cela exclurait la capacité d'une seule DLL qui peut être déposée dans un projet et fonctionner. – Josh

+0

Incluez un mini IoC dans votre composant, demandez à l'application d'enregistrer une fabrique qui implémente une interface dans votre composant et expose les méthodes pour créer les classes respectives. – svinto