C# 构建MVC应用程序模型和数据访问

我正在用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);
}

和索引模型：

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

---

那么，控制器应该包含获取数据的逻辑，还是模型应该处理它？很多MSDN示例都显示了控制器填充模型，但这似乎打破了MVC的层次。这个问题在某种程度上是基于观点的。但考虑到以下想法可能会有所帮助：

型号

• 让它负责在层之间传输数据
• 将普通类用作视图模型或输入模型
• 不要将业务逻辑或数据访问放在模型类中

查看

• 让它负责呈现UI
• 只需使用

  模型

  ，不要直接调用业务逻辑类

控制器

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

业务逻辑

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

数据访问

• 让它负责使用数据执行CRUD操作
• 虽然您可以使用ORM而不是此层，但在大型应用程序中，您也可以将此层创建为使用ORM的层

一般注意事项

• 为不同的层创建抽象
• 控制器应该依赖于模型和业务逻辑抽象
• 业务逻辑应该依赖于模型和数据访问层抽象
• 数据访问层应该依赖于模型和ORM
• 可以为不同的图层使用不同的模型类型，也可以创建共享模型库
• 您可以为横切关注点（如日志）提供一个共享库

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

通常，我的项目体系结构方法是为数据访问层（通常是类库项目）和业务层（实现业务级决策）分别设置一个项目（也是类库项目）以及一个ASP.NET MVC项目作为一个表示层项目。业务层项目具有数据访问项目的dll引用，表示层项目（ASP.NET MVC项目）应具有数据访问和业务层项目的引用

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

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

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

因此，db访问类应该通过依赖注入程序（例如Ninject）提供，并且单个操作方法不必担心如何创建对象。现在，您的操作方法只需像下面这样调用dbHelper类

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

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

另外，请注意，除了使用模型之外，您的应用程序还需要创建视图模型（VM）（从数据库返回并由业务层修改的模型，以满足特定的业务需要）

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

---

谢谢。

考虑使用依赖项注入，特别是如果您要进行大量的单元测试（例如，使用Moq）。Obaid（在上面发表文章的用户）发布了关于此的良好信息

有关更多信息，请参阅以下参考资料：

---

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

您所描述的模型只是简单的POCO或DTO。Wikipedia对模型的定义是：“直接管理应用程序的数据、逻辑和规则。”我还看到模型应该负责数据访问。那么情况如何？@BartekChyży POCOs也是一种模型。具有业务逻辑的模型通常被视为域模型（在DDD中）。这里我要说的是ASP.NETMVC（作为一个应用程序框架）。在ASP.NET MVC中，在N层体系结构中，除了有对域模型或业务模型的引用外，还需要定义视图模型和输入模型。视图模型表示将在视图中显示的数据，输入模型表示将在控制器中接收的数据。