8

所以我有一个 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。“converts”（ToBusiness 和 ToDataTransfer）完全按照他们说的做。

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

4

3 回答 3

9

我在这里唯一的困惑是为什么调用ToBusiness<User>()andToDataTransfer<Data.DTO.User>()是必要的。

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

AUserRepository应该返回 aUser而不需要任何强制转换。

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

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

UserRepository rep = new UserRepository();

User user = rep.GetById(32);

// Do Work Here

rep.Save(user);
于 2010-01-19T20:22:18.647 回答
5

我通过创建业务服务层解决了这个问题。通过这种方式，我可以通过业务服务层访问功能，该层又使用查询 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);
于 2010-01-20T19:48:57.993 回答
1

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

于 2010-01-19T20:21:03.863 回答