Arguments d'interface dans ASP.NET MVC

Je suis en train de développer un projet ASP.NET MVC, et après plusieurs semaines de recherche, j'ai un assez bon framework en place en utilisant StructureMap pour enregistrer mes dépendances au moment du bootstrap, Après avoir pensé aux objets de données transmis aux actions de mon contrôleur, j'ai commencé à me demander ... si les actions du contrôleur prenaient en compte les actions du contrôleur. interfaces ou types de béton?Arguments d'interface dans ASP.NET MVC

Il est parfaitement logique que lorsque mon contrôleur est construit par la fabrique du contrôleur, les dépendances doivent être passées dans mon constructeur en tant qu'interface, mais qu'en est-il des objets de données créés par le classeur modèle? Devraient-ils également être enregistrés dans mon conteneur IoC?

Dans le code, il ne faut que quelques lignes supplémentaires pour brancher le tout de sorte que le temps système soit assez faible. D'autre part, en fonction de la nature du framework, je n'aurai pas besoin de gérer différentes implémentations dans le produit final. Mais avec tout ce que j'ai appris sur la pérennité de mon code, la conception pilotée par interface, la conception pour la testabilité, le couplage lâche, et tous les autres mots que vous pouvez penser sur ce sujet, mon instinct me dit encore que les interfaces devraient être le chemin à parcourir.

J'espère avoir fait du sens dans mon dilemme. Est-ce que quelqu'un a des opinions fortes d'une façon ou d'une autre sur ce sujet?

TIA, -J

Source

2010-07-06 jeremyalan

Vous avez raison, c'était simplement une fausse appellation dans le titre. J'ai mis à jour le titre pour mieux refléter la question. Merci d'aider à éclaircir cela. – jeremyalan

No way. Vous ne résoudriez pas le problème que IoC est censé résoudre.

Les modèles Viewmodels doivent être considérés comme des saletés. L'IoC est bon pour échanger les détails d'implémentation. Puisque vos modèles de vue sont bêtes, quels types de détails d'implémentation pouvez-vous échanger? Les modèles View ont également des responsabilités étroites et non-orthogonales très différentes des classes injectables traditionnelles comme ILogger ou IRepository.

À mon avis, il y aurait une sérieuse sur-ingénierie et la complexité qui en résulterait (je prévois des responsabilités de localisation de service dans vos contrôleurs pour les scénarios d'édition) n'en vaudrait pas la peine.

Source

2010-07-06 21:08:17 jfar

Je suis absolument d'accord que cela va bien au-delà de la portée du modèle d'utilisation typique de l'IoC. En termes de test, je m'attends toujours à voir des interfaces mockées, plutôt que de construire des objets de données, ce qui pourrait introduire de nouvelles variables dans mon scénario de test, mais je suppose que cela pourrait être un autre argument pour garder les objets données et rien de plus. – jeremyalan

@ ph0enix Vos modèles de vue peuvent avoir une certaine logique pour composer une sortie pour une vue, mais vos paramètres d'action doivent être essentiellement des conteneurs de données sans interfaces. De plus, les interfaces rendent la liaison du modèle plus difficile qu'elle ne devrait l'être. Comment le classeur modèle pourrait-il savoir quelle implémentation utiliser? Je recommanderais de viser un modèle de vue et un modèle de paramètre pour chaque action: SRP. – Ryan

"En termes de test, je m'attends toujours à voir des interfaces moquées" Pour les modèles de vue? Pourquoi? – jfar

Répondre

Questions connexes