我们即将开始大型企业应用程序。我正在认真考虑使用ASP.NET MVC，因为：
我的团队只使用PHP进行Web开发，但对.NET winforms非常有经验（所以无论哪种方式我们都有学习曲线）。我担心的是有些人对ASP.NET MVC对大型应用程序的可扩展性表示担忧。但是从我看到的内容来看，webforms也有自己的问题。
我应该重新考虑网络表格，还是坚持我的直觉并使用ASP.NET MVC？
相关：
Should I build my next web app in ASP.NET MVC? https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc
答案 0 :(得分：30)
ASP.NET webforms是重量级的，并且在html / javascript和序列化视图状态中放弃了网页上的内容。我记得我的第一个ASP.NET网站导致GC爆炸，因为所有短暂的对象都从那个神圣的观点状态重新水化。哦，当我年轻和天真（即2年前）...你必须非常了解webforms，以便从中构建可扩展的网站。可能？当然。简单？不
ASP.NET MVC最初编码 更难，但 SO 比webforms更容易开发。最难学的东西是1）惯例又称“魔术字符串”，2）Html +内联代码又称ASP和3）html表单。
使用MVC，你无法摆脱webforms开发中常见的状态噩梦，这意味着这意味着你的网页变得微不足道。这也意味着你必须更聪明地编写你的状态。该代码也更简单，并且比传统的webforms，imho更好地扩展。
此外，使用ASP.NET进行测试几乎是不可能的，因为框架中存在硬编码和不可插入的依赖关系。 ASP.NET MVC用System.Web.Abstractions成员替换了所有这些成员，这些成员是围绕这些设计糟糕且不可测试的对象的可模拟包装器。
跑步，不要走路，去MVC。
对于显而易见的问题，如果您使用的框架位于ASP.NET框架的顶部，例如MVC或您编写的任何其他框架或其他人写的，显然其中一些言论不适用。
另一方面，如果你像早期人类那样编写了针对ASP.NET webforms模型的代码（例如，Page_Load中的Response.Write（）），我的注释就适用了。
你能编写一个可以对ASP.NET测试的代码吗？当然。你可以不用包括你或别人写的特殊测试代码吗？当然。如果你有TypeMock。
答案 1 :(得分：27)
ASP.NET WebForms与Winforms非常相似，允许RAD（快速应用程序开发）。在没有时间得到东西的速度非常快。问题是测试可能是一个主要的痛苦，如果用于任何公共面临可能意味着ViewState的一些主要问题。 WebForms可以让状态像向导一样轻松使用。
另一方面，ASP.NET MVC可能需要更长的时间来开发，并要求开发人员了解HTTP的工作原理。它是一种无状态架构，意味着每个请求都是它自己的小世界，并且通常不了解先前的请求。该框架还允许高可测试性。就性能而言，它们可能是相同的，因为ASP.NET MVC只是构建在现有ASP.NET体系结构之上的框架。虽然对于客户端体验我会说MVC要快一点。
就可扩展性而言，我认为就技术而言，它们大致相同。如何使用API并集成它MVC可能会更容易一些。
您正在使用的网站询问此版本问题是基于ASP.NET MVC构建的，它们有2个Web服务器和一个强大的数据库服务器。
答案 2 :(得分：9)
ASP.NET MVC不是Enterprise的问题，但ASP.NET，Silverlight等也不是问题。它们都是UI技术。大多数应用程序逻辑应该存在于UI层下面的库中，因此几乎可以使用任何UI。
基于以上所述，ASP.NET MVC将起作用。但是，您可以将代码移到UI下方并进行测试。如果您的算法低于UI，则可以在不更改UI的情况下调整它们。而且，如果UI层非常薄，则UI的性能影响可以忽略不计。
答案 3 :(得分：3)
没有。 ASP.NET MVC在性能方面优于ASP.NET Web Forms的一点是它不使用控制树。控制树消耗大量服务器端内存，并使垃圾收集器在具有许多控件的页面上非常繁忙。我认为你会从ASP.NET MVC中获得更好的性能。它的单元测试方面是一个真正的胜利。
另一方面，你不能使用ASP.NET Web Forms带来的所有方便的开箱即用控件，你可能最终会做更多的客户端JavaScript开发，所以最初的开发如果选择ASP.NET MVC over Web Forms，预算可能需要更大，但从长远来看，你会有一个更好的解决方案。
答案 4 :(得分：2)
坚持你的直觉。 ASP.NET MVC有助于促进测试，因为几乎整个API都来自接口。
答案 5 :(得分：1)
多年来一直使用WebForms，从不喜欢它们。现在使用Asp.Net MVC已经有好几年了，这要好得多。当然会推荐MVC。
Asp.Net MVC具有出色的架构并且是开源的。因此，如果您要识别http处理链中的bottelnecks，您可以修复它。大多数时候，您可以使用Asp.Net MVC提供的众多扩展点之一修复性能问题，例如Binders。
答案 6 :(得分：0)
如果您需要或想要它的功能，我会说与MVC一起使用。如果您正在构建一个业务线应用程序，如ERP或CRM系统，我会使用Webforms;如果你正在构建一个门户网站或社区wiki类型的网站，我会选择MVC。最终，它归结为偏好以及企业应用程序需要完成的内容。
答案 7 :(得分：0)
“使用MVC，你无法摆脱webforms开发过程中常见的状态噩梦，这意味着你的网页很容易痴迷”
为该报价上调！
答案 8 :(得分：0)
我的观点：使用ASP.NET Webforms。
在Web.Config中禁用ViewState。
没有必要保留状态，因为您真正需要的所有内容都在Request对象中。 将Javascript与AJAX结合使用以进行数据检索，以在客户端呈现UI控件。
以客户端组件渲染器的控件标记的形式创建serverside包装器。 这就是我现在已经工作多年的方式，它快速，可靠，可测试和有条理。
为这种工作方法设置一个合适的框架需要一些时间，但最终它会统治。
我宁愿没有像MVC那样的意大利面条代码。有PERL / PHP和经典ASP。
答案 9 :(得分：-2)
我读过的关于asp.net MVC的一切都说它能够提供比asp.net webforms更多的页面请求。
我对它的稳定性和安全性有些怀疑。这两者都源于它甚至没有发布它的事实，即使使用RC，我们也看到了框架的一些变化。我相信随着时间的推移会发生更多变化。它是新的，所以没有真正的“最佳实践”，并且没有丰富的经验，详细说明你可能遇到的小问题或陷阱。
我一直在使用它，它确实会导致页面更小，性能更快。但是我可以在webforms中做很多事情，我不知道如何处理mvc，因为mvc不会促进webforms控件的使用。
答案 10 :(得分：-3)
如果您能够使用存储过程，那么您不需要像MVC生成的大型中间层。您所要做的就是通过一个简单的HTTP处理程序将XML传递给存储过程，从存储过程中获取结果，并将结果转换为JSON。 MVC和其他中间层产品只能为销售像VS这样的IDE的公司赚钱。