Разделение проблем - ДАО, DTO и ФИЛИАЛ
Таким образом, у меня есть ДАО, DTO и ФИЛИАЛ. Следующий код является результатом:
// 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 называет ДАО, и в конце GetById использует AutoMapper для отображения от ДАО до DTO. "Преобразования" (ToBusiness и ToDataTransfer) делают точно, как они говорят.
Коллега моя мысль мне, вероятно, придется иметь Бизнес-Репозиторий, но думал, что это могло бы быть немного неуклюже. Какие-либо мысли?
3 ответа
Я решил это, создав уровень бизнес-сервиса. Таким образом, я могу получить доступ к функциональности через уровень бизнес-сервиса, который, в свою очередь, использует репозитории, которые запрашивают DAL и возвращает DTO. DTOS послужит своей цели, будучи населенными DAL и помогаем передавать данные на бизнес-уровень (преобразован в бизнес объекты).
Так что диаграмма выглядит следующим образом:
DAL -> Репозиторий (возврат DTO) -> Сервис (возврат Бо)
Это работает очень хорошо, и я могу поставить бизнес-логику в сервисном слое, который реферат от самого хранилища. Образец кода:
// 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);
Мой единственный источник путаницы Вот почему звонки на tobusiness и todatatransfer необходимы.
Ответственность за репозиторий состоит в том, чтобы обработать управление данными. Он должен скрыть детали реализации (а также преобразования между бизнес-объектами и объектами данных).
А UseRepository должен вернуть пользователя без какого-либо литья.
Ушнее UseRepository также может быть в состоянии сохранить пользователя без кастинга.
Код будет гораздо чище, если бы все кастинг было обработано в репозитории, и ваш код читается как:
UserRepository rep = new UserRepository();
User user = rep.GetById(32);
// Do Work Here
rep.Save(user);
Это первый раз, когда я вижу, что DTO превращается в BO, я обычно отправляет , который должен быть потребляется в классе или методом BO. Когда Босло и хочет сохранить модификации в DTO, он отправляет его в DAL и сохранил его.