Все дело в ответственности.
(я не уверен, что вы ответили именно на такой ответ - дайте мне знать, если это не так, я могу его обновить).
Таким образом, у нас есть несколько уровней в системе - каждый отвечает за свою задачу: доступ к данным, пользовательский интерфейс, бизнес-логика и т. Д. Когда мы проектируем систему таким образом, мы (среди прочего) пытаемся облегчить будущие изменения,сделать каждый компонент ответственным за одну задачу - чтобы он мог сосредоточиться на этой одной задаче и делать это хорошо.Это также облегчает модификацию системы с течением времени и необходимостью изменений.
Подобные мысли необходимо учитывать при рассмотрении DTO - "как отслеживать изменения?"например.Вот как я к этому подхожу: БЛ отвечает за управление правилами и логикой;учитывая природу Интернета без состояния (именно там я и выполняю большую часть своей работы), я просто не отслеживаю состояние объекта и не ищу явные изменения.Если пользователь передает данные обратно (для сохранения / обновления), я передам всю партию обратно, не заботясь о том, что было изменено.
Одной рукой это может показаться неэффективным, но поскольку объемы данных не являютсяэто просто не проблема;с другой стороны, чем меньше «движущихся частей», тем меньше может пойти не так, как процесс намного проще.
Как я передаю данные обратно?-
Я использую DTO (или, возможно, POCO будет более точным);когда я обмениваюсь данными между BL и DAL (через интерфейсы / DI ), данные обмениваются как DTO (или их совокупность).В частности, я использую структуру для одного экземпляра и коллекцию этих структур для нескольких.
DTO определены в общем классе, который имеет очень мало зависимостей.
Я сознательно пытаюсь ограничить количество DTO, создаваемых для конкретного объекта (например, "Порядок"), но в то же время я сделаю новые, если есть хорошийпричина.Как правило, у меня будет «толстый» DTO, который содержит большинство / все данные, доступные для этого объекта, и, вероятно, у меня будет гораздо более тонкий, который предназначен для использования в коллекциях (для списков и т. Д.).В обоих случаях эти DTO являются чистыми для возврата информации для «чтения».Вы должны помнить об обязанностях - когда BL запрашивает данные, он обычно не пытается записать данные в одно и то же время;поэтому тот факт, что DTO «только для чтения», больше соответствует соответствию чистому интерфейсу и архитектуре, чем бизнес-правилу.
Я всегда определяю отдельные DTO для вставки и обновления - даже еслиони имеют одни и те же поля.Таким образом, наихудшее, что может случиться, - это дублирование некоторого тривального кода, в отличие от наличия зависимостей и нескольких случаев повторного использования для распутывания.
Наконец - не путайте работу DALс тем, как работает пользовательский интерфейс;Позвольте ORM делать свое дело, просто потому, что они хранят данные определенным образом, не означает, что это единственный способ.
Самое важное - указать значимые интерфейсы между вашими слоями.
Управление тем, что изменилось, является работой BL;пусть пользовательский интерфейс будет работать так, как вам удобно, и пусть BL выяснит, как он хочет с этим справиться, а DAL (через ваш красивый чистый интерфейс с DI ) просто делает то, что ему говорят.