我对 MVC 4 还很陌生，到目前为止，我主要使用 C# 中的 Web 表单工作。我了解 MVC 的模式、路由、调用动作等。
但是负责从数据库中获取数据的操作呢，例如通过触发存储过程呢？我看过一些教程，他们将连接到数据库的逻辑直接放在操作中。
但是我正在考虑一种更集中的方式来做到这一点。例如，我可以将所有触发存储过程的函数放在一个名为 DatabaseCoordinator.cs 的单独类中，该类位于名为 Helpers 的文件夹中。然后我可以从控制器中的操作中调用它们。
这样我就知道我可以在一个类中找到我所有的数据库方法，我认为这是一个非常干净的解决方案（或者至少在 Web 表单中）。但是我想遵循 MVC 的模式，并且只使用模型、视图和控制器，正如模式本身的名称所暗示的那样。
那么最好的做法是什么？我应该为此创建一个单独的类，还是直接在控制器或其他地方实现逻辑？
【问题讨论】：
标签： c# asp.net-mvc-4 .net-4.5 data-access-layer
Controllers 和 Views 倾向于留在同一个项目中，但通常将 data access classes 和 models 拆分为各自独立的 class library，因为这允许其他项目使用它们。
这将允许您在未来添加 Windows 窗体/wpf 界面或移动设备界面，利用您在独立类库中已有的工作。
要考虑的另一件事是研究如何在 MVC 应用程序中使用 ViewModels。当视图需要多个 domain object 时，这是一种常用技术。 Using View Models in MVC.
【讨论】：
您当然应该创建一个单独的存储库类来包含所有数据访问操作。
【讨论】：
我建议您将数据访问代码放在控制器之外的其他位置。控制器的主要目的是收集信息以显示在页面上或反面 - 从回发的页面中获取数据并将其提供给负责业务规则和数据访问的代码。
对于大多数 MVC 项目（哎呀，真的是大多数项目！）我构建了单独的类库项目 - 至少一个用于业务规则和数据访问，尽管通常我会创建这两个单独的项目。分离逻辑的目的实际上是为了更简单的未来维护和可重用性。如果您将各个逻辑部分分开，如果您的逻辑或数据库需要更改，您可以轻松地将它们交换出来，或者您可以轻松地从新型用户界面中使用业务规则和数据；例如，如果您决定将您的项目实现为除了 Web 系统之外的 Windows 窗体应用程序，您可以（理论上）重用您的业务逻辑和数据访问逻辑库，并且只重建用户层。但是，如果您将逻辑构建到控制器中，则如果不将其提取并将其转换为您正在使用的新应用程序模型，您真的无法重用该逻辑。
因此，简而言之，绝对要让 99% 的逻辑和数据访问不受控制器的影响。仅将必须放入控制器的内容放入单独的类中，或在适当的情况下放入单独的类库中。
祝你好运！
【讨论】：
查看结合存储库模式的工作单元模式 (UOW)。无论您最终调用存储过程还是内联 linq 查询来返回结果，调用者都不应该知道或关心 GetPersons 最终是如何实现的。 UOW 模式与存储库模式相结合是在 ASP.NET 社区中公开实体框架数据库的一种非常流行的方式。您会找到不同的方法来做到这一点，有些是过度杀戮，有些只是创建没有实际好处的依赖项，但您会找到一种适合您的方式来使用这些模式。
【讨论】：
在获得更多经验后，我想更改我的答案并声明存储库模式和工作单元模式是毫无意义的抽象层，以防止您使用实体框架，这是您的数据层抽象！直接地。
除了能够从 Microsoft SQL PostgreSQL 中换出数据库（这在现实世界中什么时候会发生？）并控制您不想在代码中重复的复杂查询的结构，我认为没有真正的对存储库模式的价值。要在插入/更新中包含 CreatedBy、ModifiedBy 值，您只需覆盖 EntityFramework。要封装包含业务规则的查询，例如 where active = 1 和 isdeleted = 0，只需使用扩展方法扩展 Linq 查询。
【讨论】：