ASP.NET MVC vsWeb client software factory (WCSF)
https://stackoverflow.com/questions/53479
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Récemment, j'ai été faire un peu de recherches sur les différents types de Modèle de Vue des architectures, et la nécessité de décider lequel de poursuivre pour l'avenir le développement en interne.Comme je suis actuellement en train de travailler dans une boutique Microsoft qui a ASP.NET compétences, il semble que mes options sont entre ASP.NET MVC et WCSF (Monorail est probablement hors de la comme il ne serait pas pris en charge par Microsoft).
Après la lecture de l'ASP.NET framework MVC, à l'aide de la WCSF comme un critère, J'ai ramassé les points suivants:
- ASP.NET MVC ne peut pas utiliser les contrôles de web qui s'appuient sur les publications, alors que WCSF peut.
- Vous avez plus de contrôle sur l'url dans un ASP.NET MVC site, par opposition à un WCSF site.
- Un ASP.NET MVC site sera probablement plus facile à tester que son équivalent WCSF version.
- Il semble que la WCSF utilise toujours le code derrière pour contrôler les événements de l'UI dans certaines circonstances, mais ASP.NET MVC ne permet pas ceci.
Quelles sont les autres considérations?
Qu'ai-je mal compris?
Est-ce que quelqu'un là-bas qui est utilisé à la fois des cadres et a des conseils de toute façon?
La solution
ASP.NET MVC ne peut pas utiliser les contrôles de web qui s'appuient sur les publications, alors que WCSF peut.
Vous devriez penser à WCSF que des conseils sur la façon d'utiliser les Formulaires de l'infrastructure, en particulier l'introduction de Model-View-Presenter pour aider à faire respecter la séparation des préoccupations.Il augmente également la testabilité du code résultant.
Vous avez plus de contrôle sur l'url dans un ASP.NET MVC site, par opposition à un WCSF site.
Si vous pouvez cibler 3.5 SP1, vous pouvez utiliser le nouveau système de Routage avec un traditionnel WebForms site.Le routage n'est pas limité à la MVC.Par exemple, jetez un oeil à des Données Dynamiques (qui est également livré en 3.5 SP1).
Un ASP.NET MVC site sera probablement plus facile à tester que son équivalent WCSF version.
Cela est vrai, car il utilise les nouvelles abstractions des classes pour HttpContext, HttpRequest, HttpResponse, etc.Il n'y a rien d'intrinsèquement plus testable sur le modèle MVC que le modèle MVP.Ils sont à la fois les instances de "Présentation Séparée", et la fois d'augmenter la capacité de test.
Il semble que la WCSF utilise toujours le code derrière pour contrôler les événements de l'UI dans certaines circonstances, mais ASP.NET ne permet pas ceci.
Dans Model-View-Presenter, depuis le monde extérieur interagit avec vue (c'est à dire, les points de l'URL de la vue), les points de vue seront naturellement réagir à ces évènements.Ils devraient être aussi simples que possible, soit en appelant le présentateur ou en offrant des activités qui le présentateur pouvez vous abonner.
Modèle-Vue-Contrôleur permet de surmonter cette limitation par le monde extérieur interagir avec les contrôleurs.Cela signifie que votre point de vue peut être un peu "bête" à propos de la non-présentation des choses.
Pour que vous devriez utiliser, je pense que la réponse se résume à la mieux adaptée à votre projet, des objectifs.Parfois, WebForms riches et les pays tiers fournisseur de contrôle de la disponibilité sera préférable, et, dans certains cas, de matières simplicité et fine HTML contrôle faveur MVC.
Autres conseils
Ne pas commencer une guerre, mais la flamme j'ai trouvé le WCSF être assez compliquée.L'élégance et la simplicité de la MVC souffle MVP qui se sent comme un patron qui est à seulement greffés sur des formulaires web.
Nous avons opté pour le WCSF après avoir fait exactement la même évaluation.Nous avons estimé que le modèle MVP nous a donné plus d'options que j'ai.e Capacité à utiliser les contrôles serveur.Notre équipe de développement est composée de Programmeurs à partir d'une multitude de disciplines, je.e, C++, Biztalk et web, etc.mais tous avaient surtout porté sur le MME type de développement, de sorte que la courbe d'apprentissage en adoptant les motifs n'était pas tellement pour notre équipe.
Nous sommes plus que satisfaits de notre choix.
Vous pouvez également envisager l'arrière-plan de vos développeurs (si quelqu'un a déjà été identifié).
Si elles viennent d'une stricte asp.net arrière-plan, ils seront plus à l'aise autour de WCSF (bien que dans mon expérience, il a fallu quelques semaines pour vraiment être à l'aise autour de MVP).
Si elles viennent d'une java/rails de fond, ou ont utilisé d'autres architectures MVC avant, alors, évidemment, ils ' ll être plus heureux là-bas (et dans mon expérience, très prétentieux près rien d'autre que le MVC).
MVC est beaucoup plus simple de paradigme et est plus similaire à la façon dont tous les autres cadres de développement web.WebForms est tout simplement beaucoup trop de sauter à travers des cerceaux et de trop nombreuses couches d'abstraction pour essayer et obtenir plus de simplicité.À mon humble avis, MVC sera la valeur par défaut ASP.NET de l'architecture à l'intérieur de quelques années et de plus en plus de gens réalisent la simplicité et la facilité de développement et de tests qu'il apporte avec nous.J'ai été faire le développement MVC pour un an et demi et n'aurait jamais même penser à revenir à des WebForms sur un nouveau projet.
Un ASP.NET MVC site sera probablement plus facile à tester que son équivalent WCSF version.
Cela est vrai, car il utilise les nouvelles abstractions des classes pour HttpContext, HttpRequest, HttpResponse, etc.Il n'y a rien intrinsèquement plus testable sur le modèle MVC que le modèle MVP.Ils sont à la fois les instances de "Présentation Séparée", et la fois d'augmenter la la testabilité.
C'est sans doute discutable, mais il est de la littérature pour suggérer à l'aide d'un MVP modèle de conception est plus facile de l'unité de test, puis un modèle de conception MVC si vous avez des points de Vue qui sont emballés avec de la logique.Pour résumer, le MVP du modèle de conception le Présentateur est de gérer les travaux qui pourraient être gérées par la Vue dans le modèle de conception MVC.La logique qui pourraient être contenues dans le MVC point de Vue n'est pas de nature à faciliter les tests unitaires.Voici quelques références à la documentation que j'ai lue qui couvrirait ce concept et les raisons de garder votre Vue de la lumière est meilleure pour de nombreuses raisons, y compris la facilitation de tests unitaires.
http://martinfowler.com/eaaDev/uiArchs.html
Pourquoi ne pas joindre les deux pour les Comptoirs et de voir celle qui convient le mieux pour vous et votre situation?
