存储库和服务，MVC 模型

Question

所以我一直在学习Repository模型，似乎预计Repositories不会做很多复杂的逻辑。不过，我还了解到，大多数业务逻辑不应该位于我的控制器内部。那么我该把它放在哪里呢？

我查看了一些示例应用程序，似乎它们有另一个层，称为Services，可以为事物执行更复杂的逻辑。那么这个因素是如何融入 MVC 模式的呢？

我是否想要构建我的服务来访问我的存储库，然后构建我的控制器来访问我的服务？像这样？

interface IMembershipService
{
 bool ValidateUser(string username, string password);
 MembershipCreateStatus Create(string username, string password);
}
interface IMembershipRepository
{
 MembershipCreateStatus Create(string username, string password);
}

class MembershipRepository : IMembershipRepository
{
 public MembershipRepository(ISession session)
 {
  **// this is where I am confused...** 
 }
}
class MembershipService : IMembershipService
{
 private readonly IMembershipRepository membershipRepository;
 public MembershipService(IMembershipRepository membershipRepository)
 {
  this.membershipRepository = membershipRepository;
 }

 public bool ValidateUser(string username, string password)
 {
   // validation logic
 }
 public MembershipCreateStatus Create(string username, string password)
 {
  return membershipRepository.Create(username, password);
 }
}

class MembershipController : Controller
{
 private readonly IMembershipService membershipService;

 public MembershipController(IMembershipService membershipService)
 {
  this.membershipService = membershipService
 }
}

我的代码中标记的部分让我感到困惑。我读到的所有内容都表明我应该将我的 ISession 注入到我的存储库中。这意味着我无法将 ISession 注入到我的服务中，那么如何从我的服务中进行数据库访问呢？我不明白这里的适当流程是什么。

当我将 ValidateUser 放入我的 IMembershipRepository 时，我被告知这是“不好的”。但IMembershipRepository 是数据库访问所在的位置。这就是意图，对吗？保持数据库访问量非常少？但如果我不能在其中加入其他逻辑，那还有什么意义呢？

有人可以阐明这一点，并向我展示一个可能更可行的例子吗？

我正在使用 Fluent nHibernate、ASP.NET MVC 3.0 和 Castle.Windsor。

我是否应该做类似的事情......

class MembershipService
{
 private readonly IMembershipRepository membershipRepository;

 public MembershipService(ISession session)
 {
  membershipRepository = new MembershipRepository(session);
 }
}

并且永远不要让我的控制器直接访问存储库？

Answer 1

我读到的所有内容都说我应该将 ISession 注入到我的存储库中。

这是正确的。您需要将会话注入存储库构造函数，因为这是进行数据访问的地方。

这意味着我无法将 ISession 注入到我的服务中，那么如何从我的服务中进行数据库访问？

您不在服务中进行数据库访问。该服务依赖于注入到其构造函数中的一个或多个存储库并使用它们各自的方法。该服务从不直接查询数据库。

回顾一下：

• 存储库包含模型上的简单 CRUD 操作。这是执行数据访问的地方。这种数据访问不一定意味着数据库。这将取决于您使用的底层存储。例如，您可以调用云上的某些远程服务来执行数据访问。
• 该服务依赖一个或多个存储库来实现业务操作。此业务操作可能依赖于存储库上的一个或多个 CRUD 操作。服务甚至不应该知道数据库的存在。
• 控制器使用服务来调用业务操作。
• 为了减少不同层之间的耦合，使用接口来抽象操作。

Answer 2

interface IMembershipService
{
 bool ValidateUser(string username, string password);
 MembershipCreateStatus Create(string username, string password);
}

创建这样的服务是一种反模式。

这样的服务有多少责任？有多少理由必须改变？

另外，如果你将逻辑放入服务中，你最终会得到一个贫乏的领域。您最终将得到事务脚本样式的过程代码。我并不是说这一定是坏事。

也许丰富的领域模型不适合您，但这应该是两者之间有意识的决定，并且这种多重责任服务在任何一种情况下都不合适。

这应该是一个巨大危险信号：

public MembershipCreateStatus Create(string username, string password)
{
  return membershipRepository.Create(username, password);
}

有什么意义？为了层而层？该服务不会增加任何价值，也没有任何作用。

有很多概念缺失。

首先，考虑使用工厂来创建对象：

public interface IMembershipFactory {
    MembershipCreateStatus Create(string username, string password);
}

工厂可以封装构建实例或开始实体对象生命周期的任何逻辑。

其次，存储库是对象集合的抽象。使用工厂创建对象后，将其添加到对象集合中。

var result = _membershipFactory.Create("user", "pw");
if (result.Failed); // do stuff
_membershipRepository.Add(status.NewMembership);  // assumes your status includes the newly created object

最后，MyEntityService 类包含可以在实体上执行的每个操作的方法，这对我来说似乎非常令人反感。

相反，我尝试通过将每个操作建模为单独的命令类而不是单个服务类上的方法来更明确并更好地捕获意图。

public class ChangePasswordCommand {
    public Guid MembershipId { get; set; }
    public string CurrentPassword { get; set; }
    public string NewPassword { get; set; }
}

然后，当发送此命令时，必须执行某些操作，因此我们使用处理程序：

public interface IHandle<TMessageType> {
    void Execute(TMessageType message);
}

public class ChangePasswordCommandHandler : IHandle<ChangePasswordCommand> {

    public ChangePasswordCommandHandler(
         IMembershipRepository repo
      ) 
      {}

    public void Execute(ChangePasswordCommand command) {
      var membership = repo.Get(command.MembershipId);
      membership.ChangePassword(command.NewPassword);
    }
}

使用与 IoC 容器交互的简单类来分派命令。

这有助于避免单一的服务类，并使项目的结构和逻辑位置更加清晰。