c# - 没有领域驱动设计的知识库有用吗？

假设我的应用程序不保证完全成熟的 DDD 设置，存储库仍然有用吗？我喜欢他们屏蔽底层实现细节(例如 Entity Framework 的使用)的方式。然而，根据定义，存储库往往与聚合根相关联(这个概念对我来说仍然是一个 chalice )。

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

另外，我刚才描述的是否会被视为事务脚本方法？它当然不是 DDD，也不是 Active Record。我什至不确定 EF4 是否存在 Active Record，就像它在 Nhibernate 中一样。

我试图了解其他人在不遵循 DDD 时如何构建 n 层应用程序。

最佳答案

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

就事务脚本而言，它与您的数据层设计是正交的。事务脚本意味着每个业务操作都被分组到一个过程调用中。示例:事务脚本模式常用于服务器端的 WCF 服务调用，每个服务方法都遵循事务脚本模式。可以这样想:对于事务脚本，实际的业务逻辑不在对象中，而是写在事务脚本过程调用中。事务脚本之间可以共享公共(public)业务逻辑，但通常是通过静态方法、帮助程序等来完成的，而不是通过“纯”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 更基于对象，因为所有业务逻辑都发生在 MailService 调用中。第三个例子是传统的面向对象。只有控制流发生在服务调用中；所有业务逻辑都在 User.IsValid() 方法中处理。

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

关于c# - 没有领域驱动设计的知识库有用吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5250720/