Разделение проблем-DAO, DTO и BO

Итак, у меня есть 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) делают именно то, что они говорят.

мой коллега подумал, что мне, возможно, придется иметь бизнес-репозиторий, но подумал, что это может быть немного неуклюжим. Есть мысли?

7
.net business-objects c# domain-driven-design java

3 ответов

мой единственный источник путаницы здесь-почему вызовы ToBusiness<User>() и ToDataTransfer<Data.DTO.User>() необходимы.

ответственность репозитория заключается в управлении данными. Он должен скрывать детали реализации (а также преобразования между бизнес-объектами и объектами данных).

A UserRepository возвращает User без необходимости литья.

на UserRepository также должен иметь возможность сохранять User без литья.

код было бы намного чище, если бы все кастинги обрабатывались в репозитории, а ваш код читался как:

UserRepository rep = new UserRepository();

User user = rep.GetById(32);

// Do Work Here

rep.Save(user);
8

Я решил это, создав уровень бизнес-сервиса. Таким образом, я могу получить доступ к функциям через уровень бизнес-сервиса, который, в свою очередь, использует репозитории, которые запрашивают DAL и возвращают DTOs. DTOs служат своей цели, заполняясь 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);
4

Это первый раз, когда я вижу, что DTO превращается в бо, я обычно отправить DTO, который будет потребляться классом или методом BO. Когда бо сделано и хочет сохранить изменения в DTO, он отправляет его в DAL и сохраняет его.

1