关注点分离 - DAO、DTO 和 BO

Posted 2023-02-24

【中文标题】关注点分离 - DAO、DTO 和 BO

【英文标题】：Separation of concerns - DAO, DTO, and BO

【发布时间】：2011-01-06 23:51:44

【问题描述】：

所以我有一个 DAO、DTO 和 BO。结果如下代码：

// Instantiate a new user repository.
UserRepository rep = new UserRepository();

// Retrieve user by ID (returns DTO) and convert to business object.
User user = rep.GetById(32).ToBusiness<User>();

// Perform business logic.
user.ResetPassword();
user.OtherBusinessLogic("test");
user.FirstName = "Bob";

// Convert business object back to a DTO to save to the database.
rep.Save(user.ToDataTransfer<Data.DTO.User>());

所以我试图分离关注点，但我想摆脱这段代码中的“转换”。 “converts”实际上作为扩展对象位于业务逻辑层（DTO 层对业务逻辑层一无所知）。 DTO 本身显然只存储数据，没有任何业务逻辑。 UserRepository 调用 DAO 并在 GetById 结束时使用 AutoMapper 从 DAO 映射到 DTO。 “转换者”（ToBusiness 和 ToDataTransfer）完全按照他们所说的去做。

我的一位同事认为我可能必须拥有一个业务存储库，但认为它可能有点笨重。有什么想法吗？

【参考方案1】：

我唯一的困惑是为什么需要调用ToBusiness<User>() 和ToDataTransfer<Data.DTO.User>()。

存储库的职责是处理数据管理。它应该隐藏实现细节（以及业务对象和数据对象之间的转换）。

UserRepository 应该返回一个 User 而无需任何强制转换。

UserRepository 也应该能够在不强制转换的情况下保持 User。

如果所有转换都在存储库中处理并且您的代码读取为：

UserRepository rep = new UserRepository();

User user = rep.GetById(32);

// Do Work Here

rep.Save(user);

【讨论】：

您建议没有 DTO 对象并直接跳到业务对象？回复：更简洁的代码——我完全同意——这就是我试图使用这些关注点分离来实现的目标。

如果我在这里错了，请纠正我贾斯汀，但我不认为贾斯汀提议没有 DTO，而是建议隐藏它。存储库将调用 DTO 和 BO 之间的转换方法，这样当您编写正常的业务功能时，您永远不必看到或知道 DTO。

【参考方案2】：

我通过创建业务服务层解决了这个问题。这样，我可以通过业务服务层访问功能，该层又使用查询 DAL 并返回 DTO 的存储库。 DTO 通过由 DAL 填充来实现其目的，并帮助将数据传输到业务层（转换为业务对象）。

所以示意图如下：

DAL -> 存储库（返回 DTO）-> 服务（返回 BO）

它工作得很好，我可以将业务逻辑放在从存储库本身抽象出来的服务层中。示例代码：

// UserService uses UserRepository internally + any additional business logic.
var service = new UserService();
var user = service.GetById(32);

user.ResetPassword();
user.OtherBusinessLogic("test");
user.FirstName = "Bob";

service.Save(user);

【参考方案3】：

这是我第一次看到将 DTO 转换为 BO，我通常发送一个 DTO 以供 BO 类或方法使用。当 BO 完成并想要保存对 DTO 的修改时，它会将其发送到 DAL 并使其持久化。

【讨论】：

感谢您的回复。您可以提供的任何示例代码都会有所帮助。

我同意这一点。您应该取回您的业务对象，如果您需要转换为 DTO，则可以使用 AutoMapper 等工具进行转换。