Question

我一直在研究NerdDinner教程，其中大部分都是有道理的。我不确定的是为什么Repository直接在Controller中使用而不是Model对象。例如，如果我们想要实现我们自己的会员系统并且它有一个带有Login方法的AccountController，那么连接它的最佳解决方案是什么？ e.g。

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帐户对象处理请求并通知AccountController

我的意思是：

1登录请求进入 2 AccountController使用Account对象根据请求处理登录 3帐户对象使用AccountRepository获取登录详细信息
4帐户对象处理请求并通知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中的模型视为Controller使用的数据传输对象，以提供视图引擎。控制器是唯一与服务层连接的actor。

Answer 2

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

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

Answer 3

存储库是基础设施问题。您正在做的是让您的模型依赖于您的基础架构。这是一种落后的做法。这意味着如果你想做一些事情，比如使用依赖注入，你就必须从你的容器中解析你的模型，这对我来说没有多大意义。

另外，关键不是要将所有东西都放在一个地方。您应该努力将您的问题分成逻辑单元。通过这种方式，您可以轻松识别应用程序的哪些部分。它也适合测试。

Answer 4

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

在Domain Driven Design中，有一个不适合Account类的业务逻辑：这称为服务。您可以阅读有关DDD服务的更多信息，例here。

Answer 5

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

我认为领域模型是一组玩具或工具，你可以拿起，使用，操纵等等。玩具并不关心它们存储的位置，也不应该关注它们。您应该能够将玩具放在架子上或工具箱中。它不会影响玩具。

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

5 个答案: