Application pratique de MVC / / quand utiliser, ou ne pas utiliser MVC
J'ai vu le ASP.NET communauté bourdonnement sur MVC. Je connais les bases de son origine, et qu'il y a beaucoup de sites (sauf si je me trompe, stack overflow lui-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 ne touche généralement pas au développement web. net, je me demande ce qui suit: quand est-il approprié d'utiliser MVC et quand n'est-ce pas, et pourquoi? Exemples de grande (et terrible) utilisation de MVC serait fascinant.
Bien que je réalise qu'il existe d'autres implémentations de MVC voir d'autres langages comme RoR je suis plus intéressé par son impact pour les programmeurs.net.
Si cela a déjà été passé, mes excuses!
5 réponses
Voici mes 2 cents sur MVC pour les applications web. Pour le type d'applications GUI pour lesquelles MVC était initialement prévu, le code "listener" était requis, afin que l'interface utilisateur puisse être mise à jour lorsque les événements modifiaient les données du modèle.
Dans MVC pour le web, cela n'est pas nécessaire, vous obtenez votre Écouteur gratuitement: le serveur web, et la requête HTTP est l'événement. Donc, vraiment MVC pour le web devrait être encore plus simple. En effet, il pourrait être réduit au modèle Médiateur, où le contrôleur intervient entre le modèle et la vue.
Il y a deux choses sur lesquelles il y a beaucoup de confusion. Quelle que soit la "sagesse" conventionnelle:
Cadres != MVC
Données De Base De Données != "Modèle"
Les frameworks de développement web "full stack" ajoutent généralement beaucoup de fonctionnalités, et peuvent ou non être orientés MVC à leur base. L'une des fonctionnalités que de nombreux frameworks ajoutent est l'accès à la base de données ou la fonctionnalité de mappage relationnel d'objet, et parce que les frameworks et MVC sont confus, par la suite, les données de la base de données et la facette du modèle de MVC sont également confondues. Le modèle peut généralement être considéré comme les données sous-jacentes de l'application, mais il N'a pas besoin de provenir d'une base de données. Un bon exemple pourrait être un wiki, où le modèle/les données sous-jacentes se composent de données de révision de fichier, par exemple, à partir de RCS.
J'espère que cela aide et je suis sûr que d'autres auront beaucoup à ajouter.
Je dirais qu'un scénario très convaincant pour utiliser MVC est si vous avez un groupe de développeurs. net expérimentés qui dont ont de l'expérience avec WebForms.
Venant de cette situation moi-même (très peu d'expérience web), Je l'ai trouvé beaucoup plus productif et confortable en utilisant MVC sur WebForms.
J'ai trouvé très difficile de ramasser WebForms en raison de l'abstraction susmentionnée - (je pense que la preuve de la complexité de WebForms est que je n'ai jamais rencontré quelqu'un que je considérerais comme un WebForms "guru" c'est-à-dire connaît le cycle de vie de la Page par cœur/liaison de données back-to-front etc.).
L'utilisation de MVC m'a permis d'utiliser mon expérience. net et logicielle sans avoir besoin d'investir massivement dans l'apprentissage du framework WebForms. Non seulement cela, mais j'ai une bien meilleure compréhension de HTTP, et je pense que cela permettrait des solutions de meilleure qualité.
IMHO MVC vous permet de factoriser le code beaucoup mieux que WebForms, donc je pense que les développeurs avec beaucoup d'expérience "patterns" seront plus à l'aise dans MVC.
ASP.NET MVC n'est pas l'avenir de ASP.NET développement c'est juste une nouvelle façon de développer des sites Web avec ASP.NET. Microsoft a clairement indiqué qu'ils continueraient à soutenir et à améliorer WebForms et MVC à l'avenir.
Je ne peux pas penser à des sites Web, s'il ne serait pas approprié d'utiliser MVC. Vous pouvez également faire valoir 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 d'expérience et de préférence.
Personnellement, je ne retournerais jamais au développement de WebForms après avoir utilisé MVC sur plusieurs grands projets. WebForms à mon avis place une couche d'abstraction inutile sur http et html. Pour les prototypes rapides, vous pouvez obtenir quelque chose de plus rapide avec WebForms, mais après cela, la complication de l'abstraction rend les choses plus difficiles plutôt que plus faciles. La seule raison impérieuse d'utiliser WebForms à mon avis est le niveau riche des contrôles tiers qui sont actuellement disponible. Mais vous pouvez mélanger WebForms et MVC, donc c'est assez facile pour obtenir le meilleur des deux mondes.
Je travaille dans un magasin qui a les deux ASP.NET et les applications MVC. Je pense qu'à l'origine j'étais biaisé vers les formulaires web parce que j'ai travaillé avec eux depuis plusieurs années, mais après avoir travaillé sur quelques projets MVC, je le préfère.
Quelque chose à considérer, cependant, est que si vous avez une équipe de développeurs de formulaires Web expérimentés, les progrès initiaux dans une application MVC seront plus lents en raison de la courbe d'apprentissage, donc si le calendrier d'un projet est très serré, ce n'est peut-être pas le meilleur moment pour transition.
En dehors de cela, je ne peux pas penser à des situations où je préférerais les formulaires web sur MVC à ce stade.
Sur la base de ma propre expérience, je peux vous dire que si vous n'avez pas D'arrière-plan Winforms ou Webforms, vous pouvez vous sentir plus à l'aise sous le parapluie MVC parce que vous n'attendez rien du ASP.NET WebForms monde.
De l'autre côté, en tant que recommandation, je vous encourage à consulter d'autres frameworks MVC comme Django ou RoR qui sont plus matures pour "être de l'eau" sur la façon de penser MVC. Je suis heureux avec ASP.NET MVC mais la recherche d'autres solutions vous aide à comprendre mieux le paradigme derrière le cadre.