这是我不明白的。存储过程的传统智慧是，如果你知道一个查询将作为你的应用程序的一部分执行，并且可以用参数来描述它（它就像99.9999％的时间......其他的0.0001％是如果您创建的应用程序中查询是不可预测的，因为用户正在编写查询或其他内容）。但是，如果我这样做 - 设置触发器，级联删除，sprocs的一切 - 当我创建我的数据库，那么甚至有一个模型的重点是什么？在这种情况下，模型的唯一目的是告诉数据库“Go！”并且数据库执行所有逻辑。使MVC中的M非常无关紧要。
很抱歉，如果这看起来像是一个基于意见的问题，但我觉得我不是真正得到ASP.NET MVC的要点，如果一方面我被告知“让数据库处理尽可能多的逻辑“另一方面有LINQ，Entity等工具，它们都是用于创建查询数据库的C＃方式。
ASP.NET MVC和存储过程是反义词吗？
答案 0 :(得分：1)
首先，ASP.NET MVC和存储过程不是反义词。他们只是没有关系。但这并不意味着他们不能同时在同一个应用程序中。
我想将MVC视为演示/ UI的设计模式。 MVC中的M是您想要表示的实体。它可以是一个简单的登录模型，包含用户名和密码，或者代表社交媒体用户的更大模型，具有状态更新，朋友列表及其状态更新。对于非常小的应用程序，模型可以与数据集完全匹配;在这种情况下，您的模型可以是您的数据集。但是在较大的应用程序中，您的模型可以表示业务对象，这些对象通常与底层数据集不完全对应。
许多ASP.NET MVC示例都是使用数据集作为模型的小应用程序。但是，对于您希望从表示层中解除数据库分离的大型应用程序，这通常不是一个好的设计。在这种情况下，模型可以是业务对象，它们将位于业务逻辑层上，这可能与您的数据访问层不同。在这种情况下，模型不知道您的数据库，也不知道您是否使用存储过程或LINQ进行查询。
ASP.NET MVC应用程序也可能通过另一个应用程序的API检索和更新数据。在这种情况下，MVC应用程序的模型将是API返回或接受的数据。 API处理模型检索和持久性。
因此，MVC中的M不仅仅是数据库中的数据集。
至于查询，是的，在数据服务器上运行尽可能多的查询是一种很好的做法，因为您的数据服务器就是为此而设计的。您可以使数据服务器仅返回应用程序所需的数据。您可以通过使用存储过程或LINQ来实现此目的。我更喜欢使用LINQ而不是存储过程。如果可以的话，我会避免存储过程。但这是我的偏好。我也不喜欢在存储过程中放置任何业务逻辑。