当我使用存储库模式时，我应该将业务逻辑放在哪里？答案

【问题标题】：Where do I put business logic when I'm using the repository pattern?当我使用存储库模式时，我应该将业务逻辑放在哪里？
【发布时间】：2009-10-25 04:10:35
【问题描述】：

我正在为我的应用程序使用存储库模式。我有一个类用户。用户由电子邮件识别。 UserRepository 包含一个方法 CreateUser(User user)。有一条业务规则说用户应该有一个唯一的电子邮件。

我想实现一个事务，它首先检查电子邮件是否正在使用，如果没有，则创建用户。 我应该把这个负责检查电子邮件唯一性的代码放在哪里？

这绝对是一个商业规则；这是业务逻辑。我认为将此检查放入我的 UserRepository 实现中是不正确的。

【问题讨论】：

标签： repository-pattern

【解决方案1】：

这类事情通常出现在 (1) 服务中或 (2) 直接作为数据库约束进入架构中（通常两者兼而有之）。

使用服务，您不能直接从客户端代码访问存储库；您调用一个为您执行有用操作的服务。

例如：

public class UserService : ... {
  private Repository<User> _userRepository;

  public void CreateUser(User u) {
    // Verify that the user's email is unique.
    if ( ... ) {
      _userRepository.Create(u);
    }
  }
}

【讨论】：

【解决方案2】：

如果您正在构建一个足够大的应用程序以保证使用repository pattern，那么您将希望将此验证尽可能靠近数据，可能是数据库约束，例如唯一索引/键。这可以防止由于数据损坏而导致错误泄漏到代码中的情况。

【讨论】：

+1 绝对 - 将其放入数据库 - 永远不要依赖应用程序进行过多验证....

【解决方案3】：

假设您使用数据库进行存储，您绝对应该在数据库中的电子邮件列上添加唯一约束。

【讨论】：

【解决方案4】：

查看这篇关于 Simple Talk 的优秀文章：

Five Simple Database Design Errors You Should Avoid

参见第 4 节：

通过应用程序执行完整性

基于应用程序的支持者完整性通常认为约束对数据产生负面影响使用权。他们还选择性地假设根据需求应用规则申请是最好的途径拿。 .....

解决方案很简单。

不依赖任何东西来提供 完整性和正确性除外 数据库本身。没什么，我既不是用户也不是应用程序数据库外部。**

因此，在您的情况下 - 您的电子邮件列上的唯一约束确实应该在数据库中建模。这是放置该业务逻辑的最佳位置，从长远来看，它将使您免于痛苦。

马克

【讨论】：