摘要：我应该选择ASP.Net MVC over Web Forms还是

时间：2010-09-23 12:41:12

标签： asp.net-mvc webforms comparison dynamic-data

我已经在网上工作了7年多，我已经从html-＆gt; ASP-＆gt; ASP.Net升级了，现在又升级了ASP.Net本身。我去年开始使用MVC，但由于截止日期和MVC所涉及的复杂性，我无法做到。现在，再一次有一个新的升级 - 我开始使用ASP.Net DD（动态数据）模板（最新的一个支持数据库表并提供列表，详细信息，编辑和删除向导）。

当我深入研究时，我知道它基于MVC，所以我将使用MVC（通过DD）来构建我的网络应用程序。我已经回顾了MVC和MV之间的很多文章和比较视频。 web的表单。即使在SO上也有很多主题，我的摘要链接在下面的参考部分。事实上，MVC被证明是一种更“受控”和“可扩展”的网络开发模式，但有些人认为Web Forms仍然存在于其中（例如构建大量数据驱动的应用程序等，即Sharepoint）

  

我的网络解决方案适用于供应链   （用户必须登录到程序），所以我   不需要SEO或的功能   其他对典型网络有用的东西。   为了简化，我做了一些清单   维护（查看，添加/编辑，删除＆amp;   屏幕和一些复杂的   屏幕像亲子格子＆amp;一些   表格布局。目标仍然是   保持简单而有吸引力且@   我们的核心表现和核心可用性   （大部分工作时点击次数最少）

所以，作为一名新手MVCian，我的怀疑很少：

  • Web表单是事件驱动的，而MVC将通过控制器中定义的操作
    • 执行此操作
  • 无论我使用的是L2S还是EF，我的业务逻辑都在模型中（也由部分类扩展）
  • URL-Routing将扩展我的权力，超越传统的Querystring方法
  • 我将能够渲染我的级联复杂表格布局＆amp;使用多个视图（即部分视图和用户控件）的网格
  • 像sub-total，Grand-total等等。在视图中可以进行各种计算（希望视图可以共享/传递数据）
  • 一些时髦的GUI功能，如Frozen Grid-header / footer，滚动行，tab-view等等。不会让我看到一个凌乱的视图（或者至少这是一个干净/有组织的方式）
  • 我不会真的有'Viewstate' - 在这种情况下存储临时数据的位置？比如当前的pageindex，排序顺序等。
  • 我担心MVC可能导致一个复杂的\ lenghty系统流量很长。我会迷路吗？如果我组织得好，它可以扩展吗？

实际上，还有更多，但我希望根据上述问题，你的专家可以弄清楚我工作的那种网络应用程序，所以我只想开始投资更好的东西。不能每6个月更改一次架构/方法！

DD是否隐含了MVC？那怎么能用web-form控件呢？对不起，如果我很困惑，那么请纠正我！（大部分工作点击次数最少）

最后，这可以是一个解决方案：http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx

另见编辑部分。

参考网址:(希望这有助于像我这样的其他人）

ome关于MVC的好消息＆amp;比较 -

http://forums.asp.net/t/1459417.aspx（MVC优于精心设计的网络表单应用程序） http://www.matthidinger.com/archive/2010/02/17/why-i-love-asp.net-mvc.aspx

在洞里射击:-) http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx http://www.codethinked.com/post/2010/0 http://www.codethinked.com/post/2010/01/22/Controls-Do-Not-Make-You-More-Productive.aspx

关于这场辩论的更多观点：

  

v.good文章：   http://msdn.microsoft.com/en-us/magazine/dd942833.aspx

     

以上摘要：   http://mvark.blogspot.com/2009/08/aspnet-mvc-vs-web-forms.html

http://www.asp.net/mvc/tutorials/asp-net-mvc-overview--cs http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx http://codebetter.com/blogs/karlseguin/archive/2010/03/11/webforms-vs-mvc-again.aspx

从SO： 

http://stackoverflow.com/questions/30067/
http://stackoverflow.com/questions/361620/asp-net-mvc-vs-webforms-for-first-page-load-speed-for-big-projects/
http://stackoverflow.com/questions/712220/whats-your-choice-for-your-next-asp-net-project-webforms-or-mvc/
http://stackoverflow.com/questions/661181/asp-net-mvc-vs-webforms/
http://stackoverflow.com/questions/1035642/asp-net-mvc-vs-webforms-speed-and-architecture-comparison/
http://stackoverflow.com/questions/837831/mvc-versus-webforms/

编辑＃1：

感谢您的专家评论和评论。我想分享一些我的屏幕 - 如果有人有兴趣让你知道我一直在使用的GUI功能和网格级联 -

alt text alt text alt text

Plz不要把我和新手web-dvpr混为一谈。我很有经验我只需要知道（就像我说“我会迷失”）是否可以实现功能丰富的GUI是可以实现的，以及你在做这些事情时的体验如何...希望有所帮助： - ）

3 个答案:

答案 0 :(得分：3)

  

我担心MVC可能会导致   复杂\冗长的系统在哪里流动   是冗长的。我会迷路吗？是吗   如果我组织得好可以扩展吗？

嗯，其中一部分取决于你采用这项技术的速度。

总的来说，ASP.NET MVC与任何WebForms解决方案一样可扩展，而且在我有限的经验中，可能更是如此。您必须记住，MVC是一种非新的模式 - 应用程序开发人员已经使用了多年。它甚至不是Web开发的全新内容，尽管ASP.NET MVC使其非常容易实现，这是它的一个吸引力。

ASP.NET MVC的一些传统优势（例如可测试性）大大有助于使整个项目更易于维护和更快地构建。我在一周的时间内构建了我的第一个ASP.NET MVC网站，挂钩了几年前开发的库，但提供了一个前端Web界面。真的很简单。

你问的问题是：“我会迷路吗？”真的取决于你和你正在开发的应用程序，但只有你可以回答这个问题。你必须愿意花时间学习和理解MVC ......因为你来自WebForms背景，你会发现一些不熟悉的变化。

无论哪种方式，我个人都建议使用MVC，但是，一如既往，这取决于您的项目需求。

更新：我自己对MVC的体验非常积极。我知道并理解WebForms只是因为过去几年使用它，但我最近在我的公司开始了一个项目，因为我有选择我希望使用的技术的余地，我认为它会很有趣在Web应用程序中尝试MVC模型（Web应用程序是一项要求）。我的团队和我在桌面应用程序中有MVC的经验，但我们都缺乏一般的web开发经验（作为一个整体）。

ASP.NET MVC体验非常流畅，这是我的团队轻松过渡。我为团队订购了一些书籍，我们花了一些时间来加快理解速度，然后我们开始开发（在此步骤之前已经完成了要求 - 我们处于实施阶段）。就像我之前说过的那样，花了一个星期我们已经取得了很大的飞跃 - 生产力一直是，现在仍然非常高。我对MVC模型非常满意。

您似乎担心MVC模型会导致您的应用程序变成一堆软件，或者变得难以维护。总的来说，这远非事实。分离关注点的整个概念使MVC成为应用程序可伸缩性的理想选择，同时也提高了其可维护性和可测试性。有了这些，应用程序的增长很多取决于您的团队对MVC范例的理解以及他们作为开发人员的技能。 MVC对于每个人来说都不，也不是每个项目都是如此。在与MVC无关的可伸缩性方面还有许多其他因素需要考虑（例如，数据库的设计具有巨大影响 - 可能比您选择的任何开发范例更多）。我个人喜欢ASP.NET MVC，并且对它有很好的体验，但是你必须考虑项目的所有方面（团队成员，分配时间，预算等）来做出最终决定。

答案 1 :(得分：1)

我一直在使用MVC，因为它首次发布。我想要使​​用MVC的主要原因是由于SEO /页面加载时间是我生成的Web应用程序中的一个重要因素，我厌倦了在我们的应用程序中滥用ViewState的其他开发人员，尽管我经常解释为什么80k的主页上的ViewState是不可接受的。

我想利用路由引擎获取可爱的RESTful网址，因为那时我使用IIS7在生产中重写url但是在我的开发机器上没有它可用。使用路由意味着在部署到IIS7时我不必再次配置重写规则，因为路由在应用程序中的代码中。现在，ASP.Net 4.0 Web窗体中提供了路由引擎，因此您可以轻松地使用QueryString参数进行切换。

注意：您可以询问存储临时数据的位置，例如页面索引，排序顺序等。我通常将这些数据标记到URL上。这种方法适用于Web窗体和MVC，例如

http://example.com/products/1/asc

http://example.com/products/2/desc

当我第一次使用MVC时，我注意到的直接事情是状态管理和验证需要更多时间来实现具有许多字段，复选框，下拉菜单等的用户表单。这将增加您的开发时间，因为您必须编写自定义代码保留状态，如果你想要JavaScript客户端验证，你需要自己滚动，即没有必要的字段验证器。 ViewState不是邪恶的，很容易在Web窗体应用程序中最小化ViewState。误用ViewState的开发者是邪恶的。

总结了您提到的许多功能要求，例如：有趣的GUI功能，url重写而不是查询字符串参数，计算等可以通过MVC和Web表单实现，从最终用户的角度来看，网站看起来是一样的。 MVC提供的最大优点是设计模式的惯例。我在开发团队中强制使用MVC的原因是我希望团队中的开发人员遵循相同的约定，从而允许我们更容易地获取其他代码。我对MVC的喜爱之处在于它使SoC（Separation of Concerns）更容易实现。你没有在帖子中提到TDD（测试驱动开发），但是让TDD更容易实现，这也是MVC带来的东西。

答案 2 :(得分：1)

我目前正在开发一个ASP.NET MVC Web应用程序，并且在我自己的时间内查看了Java Spring和Rails，如果您愿意在Microsoft生态系统之外工作，那么我强烈推荐Rails作为最高效的他们三个。炒作会告诉你它快了10倍，从我所看到的看起来确实是现实，而不仅仅是炒作。

同样从我所看到的内容中，ASP.NET MVC从rails中获取了大量的设计，但没有提高生产力和易用性。

是的，我发现你没有微软生态系统之外的经验，但与ASP.NET MVC和Java Spring / JSF相比，rails非常容易学习，非常值得学习。

向下投票我，我敢。

相关问题
最新问题