ASP.NET MVC和数据繁重的应用程序

Question

我一直在学习ASP.NET MVC大约一个月了，我肯定会出售它的好处，但我发现它并不适用于所有情况。

我在几个地方读过ASP.NET MVC不适合数据密集型应用程序：

• Example 1：“数据驱动的应用程序 - 如果应用程序数据量很大，使用WebForms会更容易生活”
• Example 2：如果您的应用程序“数据量大”，那么Nick Berardi的书建议您使用Web表单。

有人可以澄清为什么ASP.NET MVC不适合数据量大的应用程序以及为什么Web表单更合适？另外，在数据繁重的应用程序和其他应用程序之间划清界线的位置在哪里？我们是在谈论数据量（数百万条记录）还是在谈论大数据模型？

Answer 1

我真的希望这一点得到澄清，因为我发现完全正确相反，我认为stackoverflow.com是MVC适用于数据驱动应用程序的证据。

我没有费心阅读第二个链接的大部分内容，但第一个链接中的断言不合格，其中许多似乎对我不对。但是，WebForms所声称的弱点足以促使我将其用于数据密集型应用程序：

• UI逻辑与代码结合，因此难以分离。
• 难以进行单元测试，因此难以使用TDD。
• 由于视图状态管理导致页面大小较重。

MVC声明的弱点非常脆弱：

• 不是事件驱动的，所以对于只知道Asp.Net Webforms的人来说，围绕它的想法可能很难。
• 第三方控制库支持不是那么强大。
• 没有ViewState（这也是一种力量）。

第一个可以被视为加号和减号一样多。第二个是错误的，因为MVC应用程序可以根据需要利用传统的服务器端控件，并利用丰富的客户端控件库和库。第三，我认为我甚至不需要和那个人说话......

在互联网上阅读这样的文章时你必须要小心 - 它们听起来权威而全面，但肉在哪里？ 为什么指出的弱点是个问题？将观点作为事实抛出是不够的。它们应该使用指标进行备份，例如，当使用平台x时，不熟悉任一平台的开发人员能够以30％的速度完成应用程序，或者平台x导致代码行数减少25％，或间接级别减少，或者其他什么。

RAD是一个加号的想法是另一个需要仔细检查的想法：RAD很快，直到你想要做某个特定控制不适合的事情，然后你碰到了一堵砖墙。它是leaky abstraction，当它失败时，您突然面临理解给定控件的设计框架和代码的完全复杂性。这可能是一个很大的挫折，并且这些控件的源代码并不总是可用。

Answer 2

对我来说没有多大意义。如果您有许多不同类型的数据，或者可能是在MVC中创建Web表单的相对困难，他们可能会猜测创建许多模型的难度。

但是，ORM（例如L2Sql，EF和Subsonic），model binders和表单生成器（我现在找不到链接）几乎使这些参数变得不可靠。

坦白说我不买。

Answer 3

我相信这些作者正在讨论将数据控件拖放到页面上的能力，例如GridViews，FormViews和其他数据绑定对象。

假设你有一个IT部门的数据库，有一个计算机表，一个打印机表，一个用于软件等。这个UI是一个非常简单的数据管理系统，基本上是一个美化的MS Access。

您可以通过在Visual Studio中将数据源和控件拖到页面上来创建一个快速/脏的WebForms应用程序，而不是使用漂亮的HTML和类库编写优雅的Web应用程序。