我已经学习 ASP.NET MVC 大约一个月了，我肯定对它的好处感到满意，但我意识到它并不适用于所有情况。
我在几个地方读到 ASP.NET MVC 不适合数据密集型应用程序：
有人能解释一下为什么 ASP.NET MVC 不适合数据量大的应用程序以及为什么 Web 表单更适合吗？此外，数据密集型应用程序和其他应用程序之间的界限在哪里？我们是在谈论数据量（数百万条记录）还是在谈论大型数据模型？
【问题讨论】：
标签： asp.net-mvc
我也非常希望澄清这一点，因为我发现事实正好相反，我认为 stackoverflow.com 是 MVC 适用于数据驱动应用程序的证据。
我没有费心阅读第二个链接的大部分内容，但第一个链接中的断言不合格，其中许多对我来说似乎是错误的。不过，WebForms 所陈述的弱点足以驱使我将其用于数据密集型应用程序：
MVC 的弱点是相当脆弱的：
第一个可以看作是加号和减号。第二个是错误的，因为 MVC 应用程序可以根据需要利用传统的服务器端控件，以及使用丰富的客户端控件和库库。第三个，好吧，我觉得我什至不需要和那个人说话……
在互联网上阅读此类文章时，您必须保持警惕 - 它们听起来权威而全面，但肉在哪里？ 为什么所陈述的弱点是个问题？仅仅将意见作为事实抛出是不够的。它们应该有指标支持，例如当使用平台 x 超过 y 时，不熟悉任一平台的开发人员能够以 30% 的速度完成应用程序，或者平台 x 导致代码行数减少 25%，或间接级别更少，或其他。
RAD 是一个优点的想法是另一个需要仔细检查的想法：RAD 速度很快，直到您想要执行某个特定控件不是为之设计的事情，然后您就碰壁了。这是一个leaky abstraction，当它失败时，您会突然面临理解给定控件的设计框架和代码的全部复杂性。这可能是一个很大的挫折，而且这些控件的源代码并不总是可用。
【讨论】：
对我来说没有多大意义。如果您有大量不同类型的数据，他们可能会猜测创建多个模型的难度，或者可能是在 MVC 中创建 Web 表单的相对难度。
但是，ORM（例如 L2Sql、EF 和 Subsonic）、model binders 和表单生成器（我现在找不到链接）几乎可以解决这些论点。
坦率地说，我不买它。
【讨论】：
我相信这些作者正在谈论将数据控件拖放到页面上的能力，例如 GridView、FormView 和其他数据绑定对象。
假设您的 IT 部门有一个数据库，其中有一个用于计算机的表、一个用于打印机的表、一个用于软件的表等。用于此的 UI 是一个非常简单的数据管理系统，本质上是一个美化的 MS Access。
您可以通过将数据源和控件拖到 Visual Studio 中的页面上来简单地创建一个快速/肮脏的 WebForms 应用程序，而不是编写一个优雅的 Web 应用程序、漂亮的 HTML 和一个类库。
【讨论】：