构建 MVC 应用程序 - 模型和数据访问答案

【问题标题】：Structuring an MVC application - Model and Data Access [closed]构建 MVC 应用程序 - 模型和数据访问
【发布时间】：2019-05-27 11:10:26
【问题描述】：

我正在用 MVC 重写一个 Web 应用程序，我试图不被架构所束缚，但是，MVC 有我想要坚持的模式

我的应用程序具有显示从数据库检索到的数据的视图。

通常，我会按如下方式编写我的控制器操作

public ActionResult Index()
{
    var model = new IndexModel();
    model = DbHelper.GetData(); // business layer
    return View(model);
}

但我一直在阅读，说应该在模型中完成数据访问，那么这样的东西更好吗？

public ActionResult Index()
{
    var model = new IndexModel();
    return View(model);
}

和IndexModel：

public class IndexModel
{
    public string EmailAddress { get; set;}
    public IndexModel()
    {
        // Fetch data in here...
        EmailAddress = DbHelper.GetEmail(); // for example
    }
}

那么，控制器应该包含获取数据的逻辑，还是应该由模型处理？很多 MSDN 示例显示了填充模型的控制器，但这似乎打破了 MVC 的层

【问题讨论】：

标签： c# asp.net .net asp.net-mvc model-view-controller

【解决方案1】：

考虑使用依赖注入，尤其是当您要进行大量单元测试时（例如，使用 Moq）。 Obaid（在上面发帖的用户）发布了很好的信息。

有关详细信息，请参阅以下参考：

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.2

注意：如上面的参考资料所示，您需要在 Startup 类中配置您的服务（或者您选择的任何类型来为 MVC 配置所有服务）。

【讨论】：

【解决方案2】：

这个问题在某种程度上是基于意见的。但考虑以下想法可能会有所帮助：

型号

让它负责在层之间传输数据。
使用普通类作为 View Models 或 Input Models。
不要将业务逻辑或数据访问放入模型类中。

查看

让它负责渲染 UI。
只使用Model，不要直接调用业务逻辑类。

控制器

让它负责处理请求并提供响应。还负责控制应用程序的流程。
控制器应该只调用业务逻辑方法，它们不应该包含任何业务逻辑
不要直接与数据访问层交互。让这个业务逻辑层承担这个责任。

业务逻辑

让它负责业务操作，例如更改数据、处理数据、搜索和加载数据。
使用数据访问层方法进行 CRUD 操作。不要直接依赖数据库。让数据访问层处理 CRUD 操作。
将每个业务方法创建为单个工作单元，

数据访问

让它负责对数据进行 CRUD 操作。
虽然您可以使用 ORM 代替此层，但在大型应用程序中，您也可以将此层创建为使用 ORM 的层。

一般注意事项

为不同的层创建抽象。
控制器应依赖模型和业务逻辑抽象。
业务逻辑应依赖模型和数据访问层抽象。
数据访问层应依赖模型和 ORM
您可以为不同的层使用不同的模型类型或创建共享模型库。
您可以使用共享库来处理日志等横切关注点。

【讨论】：

您所描述的模型只是简单的 POCO 或 DTO。维基百科对模型的定义说模型：“直接管理应用程序的数据、逻辑和规则”。我还看到该模型应该负责数据访问。那么怎么样？
@BartekChyży POCO 也是一种模型。具有业务逻辑的模型通常被视为领域模型（在 DDD 中）。这里我说的是 ASP.NET MVC（作为应用程序框架）。在 ASP.NET MVC 中，在 N-Layered 架构中，除了有对 Domain Models 或 Business Models 的引用之外，还需要定义 View Models 和 Input Models。视图模型表示您将在视图中显示的数据，输入模型表示您将在控制器中接收的数据。

【解决方案3】：

MVC（模型视图控制器）是一种管理 ASP.NET MVC 应用程序架构的更广泛的设计模式，但它不是给定应用程序应该坚持的唯一模式。最终目标是拥有整洁干净的代码、松散耦合的工件并专注于代码可重用性。

通常我的项目架构方法是为 Data-Access Layer（通常是类库项目）和 Business-Layer（实施业务级决策）分别设置一个项目（也是一个类库项目）和一个 ASP.NET MVC 项目作为 Presentation-Layer 项目。业务层项目具有数据访问项目的 dll 引用，而表示层项目（ASP.NET MVC 项目）应具有数据访问和业务层项目的引用。

现在我使用依赖注入方法在其构造函数中为控制器提供数据访问依赖项，就像这样

private IDbHelper dbHelper;
public HomeController(IDbHelper _dbHelper)
{
    dbHelper=_dbHelper;
}

因此 db-access 类应通过依赖注入器（例如 Ninject）提供，并且各个操作方法不必担心如何创建对象。现在您的操作方法应该像这样简单地调用 dbHelper 类

public ActionResult Index()
{
return View(dbHelper.GetData());
}

另外请注意，除了使用 Models，您的应用程序还需要创建 View-Models (VM)（从数据库返回并由业务层修改的模型以满足业务需求具体需求）。

所以简而言之，一个好的项目是几种不同模式和架构风格的组合，这些模式和架构风格的实现使代码可重用、整洁、易于测试。

谢谢。

【讨论】：