<分区>
假设我的应用程序不需要完整的 DDD 设置，存储库仍然有用吗？我喜欢他们屏蔽底层实现细节(例如 Entity Framework 的使用)的方式。然而，根据定义，存储库往往与聚合根相关联(这个概念对我来说仍然是一个 chalice )。
我想这个问题也可以这样提出:如果我有一个典型的 3 层应用程序，其业务层外观由基于功能的“逻辑分组”类组成(而不是 DDD 中的聚合根)，例如TradingManager 和 ContactsManager，创建“逻辑分组”存储库是否有意义。或者可能是一个数据访问对象，我认为它就像一个没有聚合根要求的存储库。当然，我仍然会有一个模型(EF POCO)，它会在层之间上下传递。
另外，我刚才描述的是否会被视为事务脚本方法？它当然不是 DDD，也不是 Active Record。我什至不确定 Active Record 是否像 Nhibernate 一样存在于 EF4 中。
我试图了解其他人在不遵循 DDD 时如何构建 n 层应用程序。
最佳答案
正如您所暗示的，听起来您更倾向于 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 更基于对象，因为所有业务逻辑都发生在 MailService 调用中。第三个例子是传统的 OO。只有控制流发生在服务调用中；所有业务逻辑都在 User.IsValid() 方法中处理。
这一切都归结为您放置业务逻辑的位置。
关于c# - 如果没有领域驱动设计，存储库是否有用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5250720/