当前位置：文江博客话题详情

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

发布于 2024-08-08 08:20:43 字数 262 浏览 6 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

紫轩蝶泪 2024-08-15 08:20:43

这类事情通常进入（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);
    }
  }
}

This sort of thing typically goes in either (1) a service or (2) directly into the schema as a database constraint (and frequently both).

Using a service, you don't access the Repository directly from client code; you call a service which does the useful operations for you.

For example, something like:

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

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

回复收藏 0 原文

聚集的泪 2024-08-15 08:20:43

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

回复收藏 0 原文

你是暖光i 2024-08-15 08:20:43

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

回复收藏 0 原文

逆流 2024-08-15 08:20:43

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

您应该避免的五个简单数据库设计错误

请参阅第 4 节：

通过应用程序加强完整性
基于应用程序的支持者
诚信通常认为
约束对数据产生负面影响
使用权。他们还选择性地假设
根据需要应用规则
该应用程序是最好的途径
拿。 ......
解决方案很简单。
不依赖任何其他提供
完整性和正确性除外
数据库本身。毫无疑问，我
既不是用户也不是应用程序
数据库外部。**

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

马克