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

我正在为我的应用程序使用存储库模式。我有一个类的用户。用户通过电子邮件标识。 UserRepository包含一个CreateUser（用户用户）方法。有一个业务规则说用户应该有一个独特的电子邮件。当我使用存储库模式时，我在哪里放置业务逻辑？

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

这绝对是一个商业规则;这是商业逻辑。我认为把这个检查放在我的UserRepository实现中是不正确的。

来源

2009-10-24 Markus

这种事情通常在（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); 
    } 
    } 
}

来源

2009-10-24 18:39:59

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

来源

2009-10-24 18:33:00

如果你正在构建大到足以warrent一个repository pattern然后应用你会希望把这个验证尽可能靠近数据成为可能，大概一个数据库约束，如唯一的索引/键。这可以防止由于数据损坏而导致错误再次泄漏到代码中的情况。

来源

2009-10-24 18:45:19

+1绝对 - 把它放在数据库中 - 永远不要依靠应用程序做太多的验证.... – 2009-10-24 20:07:01

检查出浅谈这个优秀的文章：

Five Simple Database Design Errors You Should Avoid

见第4节：基于完整性通常

强制实现完整性通过应用程序的

支持者认为，限制对数据访问造成负面影响。他们还有选择地根据的需要应用规则应用程序是采取的最佳路线。 .....

解决方法很简单。

依靠闲来无事提供 完整性和正确性除 数据库本身。通过什么都没有，我的意思是既不用户，也不应用外部数据库**

所以你的情况 - 在电子邮件列中的唯一约束确实应该在数据库建模。这是放置这种商业逻辑的最佳场所，并且从长远来看可以让你免于很多悲伤。

Marc

来源

2009-10-24 20:10:35

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

回答

相关问题