1

我对 MVC 4 还很陌生，到目前为止，我主要使用 C# 中的 Web 表单。我了解 MVC 的模式、路由、调用动作等。

但是负责从数据库中获取数据的操作呢，例如通过触发存储过程呢？我看过一些教程，他们将连接到数据库的逻辑直接放在操作中。

但是，我正在考虑一种更集中的方式来做到这一点。例如，我可以将所有触发存储过程的函数放在一个名为 DatabaseCoordinator.cs 的单独类中，该类位于名为 Helpers 的文件夹中。然后我可以从控制器中的操作中调用它们。

这样我就会知道我可以在一个类中找到我所有的数据库方法，我认为这是一个非常干净的解决方案（或者至少在 Web 表单中）。但是我想遵循 MVC 的模式，并且只使用模型、视图和控制器，正如模式本身的名称所暗示的那样。

那么最好的做法是什么？我应该为此创建一个单独的类，还是直接在控制器或其他地方实现逻辑？

4

5 回答 5

6

您当然应该创建一个单独的存储库类来包含所有数据访问操作。

这里有一个很好的例子： http ://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-在-an-asp-net-mvc-应用程序中

于 2013-09-09T16:48:27.293 回答
5

我建议您将数据访问代码放在控制器之外的其他地方。控制器的主要目的是收集信息以显示在页面上或反面 - 从回发的页面中获取数据并将其提供给负责业务规则和数据访问的代码。

对于大多数 MVC 项目（哎呀，真的是大多数项目！）我构建了单独的类库项目 - 至少一个用于业务规则和数据访问，尽管通常我会制作这两个单独的项目。分离逻辑的目的实际上是为了更简单的未来维护和可重用性。如果您将各个逻辑部分分开，如果您的逻辑或数据库需要更改，您可以轻松地将它们交换出来，或者您可以轻松地从新型用户界面中使用业务规则和数据；例如，如果您决定将项目实现为除了 Web 系统之外的 Windows 窗体应用程序，您可以（理论上）重用您的业务逻辑和数据访问逻辑库，并且只重建用户层。但是，如果您将逻辑构建到控制器中，您真的可以

因此，简单地说，绝对让 99% 的逻辑和数据访问不受控制器的影响。仅将必须放入控制器的内容放入单独的类中，或者在适当的情况下放入单独的类库中。

祝你好运！

于 2013-09-09T16:55:37.490 回答
3

Controllers和Views倾向于留在同一个项目中，但通常将 和 拆分为data access classes它们models自己的单独的class library，因为这允许其他项目使用它们。

这将允许您在未来添加 Windows 窗体/wpf 界面或移动设备界面，利用您在独立类库中已有的工作。

要考虑的另一件事是研究如何ViewModels在 MVC 应用程序中使用。当 View 需要多个domain object. 在 MVC 中使用视图模型。

于 2013-09-09T16:50:57.053 回答
2

查看结合存储库模式的工作单元模式 (UOW)。无论您最终调用存储过程还是内联 linq 查询来返回结果，调用者都不应该知道或关心 GetPersons 最终是如何实现的。UOW 模式与存储库模式相结合是在 ASP.NET 社区中公开实体框架数据库的一种非常流行的方式。你会找到不同的方法来做到这一点，有些是过度杀伤，有些只是创建没有实际好处的依赖关系，但你会找到一种适合你的方式来使用这些模式。

于 2013-09-09T16:52:16.010 回答
1

经过更多的经验，我想改变我的答案并声明存储库模式和工作单元模式是毫无意义的抽象层，以防止您使用实体框架，这是您的数据层抽象！直接地。

除了能够从 Microsoft SQL PostgreSQL 中换出数据库（这在现实世界中什么时候会发生？）并控制您不想在代码中重复的复杂查询的结构，我认为它没有真正的价值存储库模式。要在插入/更新中包含 CreatedBy、ModifiedBy 值，您只需覆盖 EntityFramework。要封装包含业务规则的查询，例如 where active = 1 和 isdeleted = 0，只需使用扩展方法扩展 Linq 查询。

于 2013-11-13T21:47:16.233 回答