Application pratique de MVC || Quand utiliser ou ne pas utiliser MVC

Question

J'ai vu le ASP.NET communauté animée sur MVC. Je connais les bases de son origine, et qu'il existe de nombreux sites (sauf erreur de ma part, de débordement de pile elle-même), basé sur ASP.NET MVC.

De tout ce que j'ai entendu et lu sur MVC, il semble être l'avenir de ASP.NET développement. Mais comme je n'ai pas l'habitude barboter dans .NET développement web, je suis sorti en me demandant la suivante: quand est-il approprié d'utiliser MVC et quand est-il pas, et pourquoi? Des exemples de grands (et terrible) utilisation de MVC serait fascinant.
Si je me rends compte il existe d'autres implémentations de la MVC vue d'autres langues comme le RoR je suis plus intéressé sur son impact pour .NET programmeurs.

Si cela a déjà été dépassé, toutes mes excuses!

Answer 1

Ici sont mes 2 cents sur MVC pour les applications web. Pour le tri des applications à interface graphique pour qui MVC était prévu à l'origine, "auditeur", le code a été nécessaire, afin que l'INTERFACE d'utilisateur peut être mis à jour lorsque des événements ont modifié le modèle de données.

Dans MVC pour le web c'est inutile, vous obtenez votre écouteur pour gratuit: le serveur web, et la requête HTTP EST le cas. Si vraiment MVC pour le web devrait être encore plus simple. En effet, il pourrait être bouilli vers le bas pour le Médiateur, par lequel le Contrôleur est le médiateur entre le modèle et la vue.

Il y a deux choses qu'il y a beaucoup de confusion au sujet de. Quel que soit classique "sagesse":

Cadres != MVC

Base De Données De Données != "Modèle"

"Full stack" du développement web cadres généralement ajouter beaucoup de fonctionnalités, et peut ou peut ne pas être MVC-orientée à leur base. L'une des caractéristiques de nombreux cadres d'ajouter une base de données d'accès ou le mapping objet-relationnel fonctionnalité, et parce que les cadres et MVC se confondre, par la suite la base de données et le modèle de facette de la MVC aussi se confondre. Le modèle peut généralement être considérée comme sous-jacents des données de l'application, mais il n'a PAS à venir à partir d'une base de données. Un bon exemple peut être un wiki, où le modèle sous-jacent/données se compose de révision du fichier de données, par exemple, à partir de RCS.

Espérons que cela aide, et je suis sûr que d'autres ont beaucoup de choses à ajouter.

Answer 2

Je voudrais dire un très convaincante scénario à utiliser MVC est si vous avez un groupe d'expérience .NET développeurs qui n' ont de l'expérience avec les Formulaires web.

Venant de cette situation moi-même (très peu d'expérience sur le web) je l'ai trouvé j'ai été beaucoup plus productif et confortable à utiliser MVC sur WebForms.

Je l'ai trouvé très dur à la collecte de Formulaires web en raison de cette abstraction - (je pense que la preuve de WebForms complexité est que je n'ai jamais rencontré quelqu'un que je considère comme un WebForms "gourou" c'est à dire sait que la Page du Cycle de vie par cœur/de Liaison de Données de l'arrière vers l'avant, etc.).

En utilisant MVC en fait m'a permis d'utiliser mon .NET et le logiciel de l'expérience sans avoir à investir massivement dans l'apprentissage de la WebForms cadre. Non seulement cela, mais j'ai eu une bien meilleure compréhension de HTTP, et c'est, je pense, permettre plus de solutions de qualité.

À mon humble avis MVC permet de facteur de code beaucoup mieux que WebForms, donc je pense que les développeurs avec beaucoup de "modèles" de l'expérience sera plus à l'aise dans MVC.

Answer 3

ASP.NET MVC n'est pas l'avenir de ASP.NET le développement c'est juste une nouvelle façon de développer des sites web avec ASP.NET. Microsoft ont indiqué clairement qu'ils vont continuer à soutenir et à améliorer les WebForms et MVC dans l'avenir.

Je ne vois pas de sites web, s'il ne serait pas approprié d'utiliser MVC. Vous pourrait aussi affirmer la même chose pour les Formulaires web.

Si vous choisissez l'un sur l'autre est un choix personnel, et dépendra de l'équipe de développement de l'expérience et des préférences.

Personnellement, je n'aurait jamais revenir à des WebForms développement après l'utilisation de MVC sur plusieurs grands projets. WebForms, à mon avis, place une inutile de la couche d'abstraction sur http et html. Rapide de prototypes que vous pouvez obtenir quelque chose de mal ficelées plus rapide avec les Formulaires web, mais après que la complication de l'abstraction rend les choses plus difficiles plutôt que facile. La seule raison valable pour l'utilisation de Formulaires web, à mon avis, c'est la riche niveau de la 3e partie des contrôles qui sont actuellement disponibles. Mais vous pouvez mélanger des WebForms et MVC, de sorte que son assez facile à obtenir le meilleur des deux mondes.

Answer 4

Je travaille dans un magasin qui a les deux ASP.NET et les applications MVC. Je pense qu'à l'origine j'ai été orientée vers les formulaires web parce que j'ai travaillé avec eux depuis plusieurs années, mais après avoir travaillé sur quelques projets MVC que je le préfère.

Quelque chose à considérer, cependant, est que si vous avez une équipe expérimentée de formulaire web développeurs premiers progrès dans une application MVC sera plus lent en raison de la courbe d'apprentissage, donc si le montage d'un projet est très serré, il pourrait ne pas être le meilleur moment de la transition.

Mis à part cela je ne peux pas penser à des situations où je préfère formulaires web sur MVC à ce point.

Answer 5

Basé sur ma propre expérience, je peux vous dire que si vous n'avez pas de Winforms ou Webforms arrière-plan, vous pouvez vous sentir plus à l'aise sous le MVC parapluie, car vous n'êtes pas "attendre" quelque chose de l'ASP.NET Webforms monde.

De l'autre côté, en tant que recommandation, je vous invite à consulter d'autres MVC, frameworks comme Django ou RoR qui sont plus matures à "l'eau" sur le MVC façon de penser. Je suis heureux avec ASP.NET MVC, mais à la recherche d'autres solutions vous aide à mieux comprendre le paradigme derrière le cadre.