如果没有域驱动设计,存储库是否有用？

Question

假设我的应用程序不能保证完整的DDD设置,那么存储库是否仍然有用？我喜欢他们屏蔽下面的实现细节(例如使用实体框架)的方式.然而,根据定义,存储库往往与Aggregate Roots(这个概念对我来说仍然是一个圣杯)联系在一起.

我想这个问题也可以这样说:如果我有一个典型的3层应用程序,其业务层外观由基于功能的"逻辑分组"类组成(而不是像DDD中的聚合根),例如TradingManager和ContactsManager ,创建"逻辑分组"存储库是否有意义.或者也许是数据访问对象,我认为它就像没有聚合根要求的存储库.当然,我仍然会有一个模型(EF POCOs),它们将在各层之间上下传递.

另外,我刚才描述的是否会被视为交易脚本方法？它肯定不是DDD,而不是Active Record.我甚至不确定EF4是否存在Active Record与Nhibernate一样.

我试图了解其他人如何在不遵循DDD的情况下构建n层应用程序.

Answer 1

正如你所暗示的那样,听起来你更喜欢DAO.我认为DAO在非DDD项目中非常有用,在这些项目中,您希望完全抽象出数据层技术.

就事务脚本而言,它与您的数据层设计正交.事务脚本意味着每个业务操作都被分组为一个过程调用.示例:事务脚本模式通常用于服务器端的WCF服务调用,每个服务方法都遵循事务脚本模式.可以这样想:使用事务脚本,实际的业务逻辑不在对象中,而是在事务脚本过程调用中直接写入.通用业务逻辑可以在事务脚本之间共享,但通常通过静态方法,帮助程序等来完成,而不是通过"纯"OO完成.

这是一些伪代码

// traditional transaction script
public class MailService
{
    public void UpdateEmail(string userName, string newEmail)()
    {
       if(db.UserExists(userName))
       {
          if(EmailHelper.ValidateEmailFormat(newEmail))
          {
             db.UpdateEmail(userName, newEmail);
          }
       } 
    }
}

// transaction script with anemic domain objects
public class MailService
{
    public void UpdateEmail(string userName, string newEmail)()
    {
       var userDAO = new UserDAO();
       var emailDAO = new EmailDAO();

       var existingUser = userDAO.GetUserByName(userName);       

       if(existingUser != null)
       {
          if(EmailHelper.ValidateEmailFormat(newEmail))
          {
             emailDAO.UpdateEmail(existingUser, newEmail);
          }
       } 
    }
}  

// More of an OO / DDDish approach
public class MailService
{
    public void UpdateEmail(string userName, string newEmail)()
    {
       var userRepository = new Repository<User>();

       var userToUpdate = userRepository.Where(x => x.UserName = userName).FirstOrDefault();

       if(userToUpdate != null)
       {
           userToUpdate.Email = newEmail;

           if (user.IsValid())
           {
               userRepository.Update(userToUpdate);
           } 
       }
    }
}

显然,第一个例子根本不是OO.第二个示例比OO更基于对象,因为所有业务逻辑都发生在MailService调用中.第三个例子是传统的OO.服务调用中只发生控制流; 所有业务逻辑都在User.IsValid()方法中处理.

这一切都归结为您放置业务逻辑的位置.