MVC 4中数据库方法的最佳实践

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

因此，简单地说，绝对保持99％的逻辑和数据访问权限。只将您必须放入控制器的内容，其余内容放在单独的类中，或者在适当的位置放在单独的类库中。

祝你好运！

Answer 3

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

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

另一件需要考虑的事情是研究如何在MVC应用程序中使用ViewModels。当Views需要多个domain object时，这是一种常见的技术。 Using View Models in MVC

Answer 4

结合存储库模式检查工作单元模式（UOW）。如果您最终调用存储过程或内联linq查询以返回结果，则无关紧要，您的调用者不应该知道或关心GetPersons最终如何实现。 UOW模式与Repository模式相结合是在ASP.NET社区中公开Entity Framework数据库的一种非常流行的方式。你会发现不同的方法，有些是过度杀戮，有些只是创造依赖，没有实际的好处，但你会发现这种模式对你感觉合适。

Answer 5

经验丰富之后，我想改变我的回答并声明存储库模式以及工作单元模式是无意义的抽象层，以防止您使用Entity Framework，这是您的数据层抽象！直。

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