可以从自定义模型绑定器访问数据库吗？

Question

假设我有一个对象，它从 HttpPost 获取一些数据，从数据库获取一些数据。我想我想允许 ModelBinder 访问数据库/存储库以获取帖子中丢失的数据。实际上，这是一个好主意还是坏主意？

Answer 1

鉴于我对此类事情的思考自 2010 年初以来已经发生变化，我决定编辑我原来的答案。

在我原来的答案中，我基本上表达了这一点，虽然我的直觉告诉我你不应该这样做，但我很不舒服地说我们不应该在无法阐明原因的情况下。

现在，我建议不要这样做，因为模型绑定器的职责是将用户请求转换为请求模型，并且检索可从请求派生的数据之外的数据超出了此责任范围。

Answer 2

我想说一个坏主意。模型绑定器的想法是，它从请求中获取参数并根据这些参数创建模型。如果您的模型绑定器在幕后填充数据库中的一些详细信息，这会破坏范例。我宁愿通过直接从数据库显式获取所需的额外数据来公开控制器中的数据库调用。请注意，如果经常使用，可以将其重构为方法。

Answer 3

我认为这非常好并且一直使用这种技术。

唯一反对的论点非常迂腐，相当于哲学争论。恕我直言，您可以将“填充丢失的已发布数据”代码作为基本控制器中的方法与 ActionFilter 中的方法与 ModelBinder 中的方法放入 MVC 应用程序中。这完全取决于谁承担什么责任。对我来说，模型绑定器可以做的不仅仅是简单地从发布的值连接一些属性。

我喜欢在 modelbinder 中进行数据库调用的原因是它有助于清理您的操作方法。

    //logic not in modelbinder
    public ActionResult Edit( KittyCat cat )
    {
        DoSomeOrthagonalDatabaseCall( cat );

        return View( new MODEL() );
    }

与

    //logic in model binder
    public ActionResult Add( KittyCat cat )
    {
        return View( new MODEL() );
    }

Answer 4

它违反了 MVC 的工作方式。 ModelBinder 用于从来自视图的数据中绑定模型。填充数据库中缺失的信息应该由控制器处理。理想情况下，它应该具有用于​​执行此操作的相同数据层/存储库类。

它应该在控制器中的原因是因为该代码是业务逻辑。业务规则规定某些数据可能会丢失，因此必须由操作的大脑（即控制器）来处理。

更进一步，假设您想在数据库中记录用户未发布的信息，或者在获取丢失的数据并向管理员发送电子邮件时捕获异常。您必须以这种方式将它们放入模型绑定器中，并且随着模型绑定器变得越来越偏离其原始用途，它会变得越来越难看。

基本上，您希望除了控制器之外的所有东西都尽可能愚蠢和专业化，只知道如何执行其特定的专业领域，这纯粹是为了协助控制器。

Answer 5

我会说，不。

原因如下：它将创建对数据库的依赖关系，以测试控制器操作，而这种依赖关系不容易抽象出来。

Answer 6

我会说没关系。创建对数据库的依赖关系的参数是一个错误的参数，原因有两个：

1- 数据库访问应该通过存储库接口进行抽象。存储库接口是域模型的一部分，其实现是基础设施/数据访问层的一部分。所以对数据库没有依赖性。

2-模型绑定器和控制器都是使用 ASP.NET MVC 框架实现的表示层的一部分。如果允许控制器使用存储库接口访问数据库，为什么不允许模型绑定器？

此外，在某些情况下，您“最好”从模型绑定器填充模型中缺失的数据。考虑视图上有一个下拉列表的场景。第一次加载视图时，会填充下拉列表。用户提交表单但验证失败。因此，您需要再次退回表格。在此阶段，您必须重新填充下拉列表模型中的列表。在控制器中执行此操作看起来很丑陋：

public ActionResult Save(DocumentViewModel viewModel)
{
     if (!ModelState.IsValid)
     {
         viewModel.Categories = _repository.GetAll();
         return View(viewModel);
     }
}

我相信这里的类别初始化很丑陋并且就像代码味道一样。如果您有一些需要从数据库填写的属性怎么办？如果您有超过 1 个以 DocumentViewModel 作为参数的操作怎么办？你必须一遍又一遍地重复这个丑陋的步骤。更好的方法是使用模型绑定器填充模型的所有属性并将其传递给控制器​​。因此传递给控制器​​的对象处于“一致”状态。