关注点分离 - DAO,DTO和BO

Question

所以我有一个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>());

所以我试图分开关注点,但我想摆脱这段代码中的"转换"."转换"实际上位于业务逻辑层(DTO层不知道业务逻辑层)作为扩展对象.DTO本身显然只存储数据,并且没有任何业务逻辑.UserRepository调用DAO,在GetById结束时使用AutoMapper从DAO映射到DTO."转换"(ToBusiness和ToDataTransfer)完全按照他们的说法行事.

我的一位同事认为我可能需要有一个商业资源库,但认为它可能有点笨重.有什么想法吗？

Answer 1

我这里唯一的混乱来源是为什么要求ToBusiness<User>()和ToDataTransfer<Data.DTO.User>()必要.

存储库的职责是处理数据管理.它应该隐藏实现细节(以及Business Objects和Data Objects之间的转换).

A UserRepository应返回a User而不需要任何铸造.

该UserRepository也应该能够坚持一个User没有铸造.

如果在存储库中处理所有转换并且您的代码读取为:代码将更加清晰:

UserRepository rep = new UserRepository();

User user = rep.GetById(32);

// Do Work Here

rep.Save(user);

Answer 2

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

因此，该图如下所示：

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

它工作得很好，并且我能够将业务逻辑放在Service层中，该逻辑从Repository本身抽象出来。样例代码：

// 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);