控制器或模型中的存储库？

Question

我一直在学习 NerdDinner 教程，其中大部分都很有意义。 我不确定为什么在控制器中直接使用存储库而不是模型对象。 例如，如果我们想实现自己的会员系统，并且它有一个带有 Login 方法的 AccountController，那么连接它的最佳解决方案是什么？ 例如

Login(username,password){

    repo = AccountRepository

    account = repo.getLogin(username,password)

    //check account isn't locked

    //check account has been verified etc etc 

    //throw error or proceed to secure area

}

OR

Login(username,password){

    repo = AccountRepository

    account = repo.getLogin(username,password)

    account.login() //business logic is handled in Account (Model)

}

OR

Login(username,password){

    //no reference to repository

    account = Account

    //Account (Model) uses repository and handles business logic
    account.login(username,password) 

}

我建议让 Account 对象直接使用 AccountRepository，而不是 AccountController 从 AccountRepository 获取信息，然后将其传递给 Account 对象，例如

NerdDinnner 风格：

1 登录请求进来
2 AccountController 使用 AccountRepository 根据请求获取登录详细信息
3 AccountController 使用 Account 对象并传入步骤 1 中的信息
4 Account 对象处理请求并通知 AccountController

我的建议是：

1 登录请求进来
2 AccountController根据请求使用Account对象处理登录
3 Account对象使用AccountRepository获取登录详细信息
4 Account 对象处理请求并通知 AccountController

后一种样式的原因是，从 AccountRepository 返回登录详细信息后，将遵循业务规则，例如帐户是否锁定、帐户是否验证等。如果使用第一种样式，则获取逻辑详细信息和使用它们分为两个步骤。 后一种风格将所有逻辑保持在一起，同时仍然使用 AccountRepository，例如

Account.Login(username,password){
    repo = AccountRepository

    account = repo.GetLogin(username,password)

    //check account isn't locked

    //check account has been verified etc etc

    //throw error or proceed to secure area
}

我希望这是有道理的。

Answer 1

mvc 中的“模型”是表示模型而不是领域模型。 您可以将 MVC 中的模型视为控制器用来向视图引擎提供数据的数据传输对象。
控制器是与服务层连接的唯一参与者。

Answer 2

您至少应该有另一层（不是控制器）负责与存储库接口交互。 这允许将 UI（控制器是它的一部分）更改为另一个。 这样，无论是命令行、桌面还是 Web 界面都无关紧要。

在 ASP.NET MVC 中，我更喜欢将模型（不是我的域模型，MVC 模型）放在一个单独的项目中，而不是放入 MVC 项目中。 这允许与其他类型的 UI 共享 DTO（MVC 模型）。

Answer 3

存储库是一个基础设施问题。 您正在做的就是让您的模型依赖于您的基础设施。 这是一种落后的做法。 这意味着，如果您想要执行诸如使用依赖项注入之类的操作，则必须从容器中解析模型，这对我来说没有多大意义。

另外，重点并不是要把所有东西都放在同一个地方。 您应该努力将您的关注点分成逻辑单元。 通过这种方式，您可以轻松识别应用程序的哪个部分执行什么操作。 它还适合于测试。

Answer 4

我想说的是，执行登录的不是帐户，而是您使用该帐户登录应用程序，因此在帐户上调用 Login 方法似乎有点不自然。

在领域驱动设计中，有一个不适合 Account 类的业务逻辑位置：这称为服务。 您可以在此处了解有关 DDD 服务的更多信息。

Answer 5

我会避免将数据访问放入模型中。 这很可能导致模型对存储机制的依赖。 我通常会将此逻辑放置在服务/业务逻辑层中，该层将与数据层和模型进行对话。 在您只有模型和控制器的情况下，控制器将完成这项工作。

我认为领域模型是一组玩具或工具，你可以拿起、使用、操纵等等。玩具并不真正关心它们存储在哪里，也不应该关心它们。 您应该能够将玩具放在架子上或工具箱中。 对玩具没有影响。