Использование DTO в качестве бизнес-объектов - не лучшее решение, которое вы можете принять.Исходя из своего опыта, я могу сказать, что обычно, когда ваши объекты идентичны для всех слоев, вероятно, где-то существует проблема с архитектурой.
В реальном бизнес-сценарии весьма маловероятно, что бизнес-логика на сервереи бизнес-логика на клиенте имеет одинаковый контекст и работает с одинаковыми объектами.И если они имеют точно такую же структуру с базой данных ... хммм ... звучит как приложение, управляемое данными.
Но если это , то это приложение, управляемое данными, когда клиенты получают доступнекоторые данные, измените их и сохраните обратно, тогда, возможно, вам не нужен этот сложный уровень?Звучит просто, так что давайте будем простыми.Если является приложением, управляемым данными, почему бы просто не создать контекст WCF DataServices поверх вашей базы данных и позволить ему выполнять всю грязную работу за вас, когда вы просто получаете доступ к своим даннымнад WCF, даже не задумываясь о DTO, сопоставлениях и т. д.
Если это , а не приложение, управляемое данными, то у вас, вероятно, есть некоторая сложная бизнес-логика на стороне сервера, и этот бизнесЛогика обычно оперирует объектами, которые имеют смысл только в контексте.Просто не имеет смысла проталкивать эти объекты вплоть до пользовательского интерфейса.
Вместо этого пользовательский интерфейс, вероятно, будет отправлять команды на сервер для запроса системы сделать что-то .Например, он будет отправлять команду «DisableAccount (id = 123)» вместо загрузки AccountDTO, изменяя свой флаг IsEnabled на false и толкая его обратно.Если является бизнес-логикой, то она, вероятно, будет вызвана такой командой от клиента, которому не нужно знать , как отключить учетные записи или какделать другие вещи.Он просто знает и может дать команду системе сделать что-то.
Так что в этом сценарии клиенту (UI) просто не нужен тот же объект, который есть у сервера.Может потребоваться, чтобы некоторые данные отображались пользователю, но они определенно будут в формате, который имеет смысл для представления клиента, а не для бизнес-логики.Вероятно, он будет содержать некоторые денормализованные данные, как-то объединенные.
Скажем, пользователь для пользовательского интерфейса не является DTO, сопоставленным с таблицей пользователей.Это еще один DTO, содержащий пользовательские данные и статистику из разных таблиц, как-то обработанные.Клиенту не нужно знать внутреннюю структуру хранилища данных на сервере, поэтому нет необходимости раскрывать его.Получите соответствующие данные и отправьте соответствующие команды, вот и все.
Сказав все это, я должен подчеркнуть, что это НЕ бинарный выбор, который вы делаете.Для простых функций вы можете использовать простой подход, а для функций, в которых логика имеет смысл, вы можете делать и другие вещи.
Вам не нужно выбирать один для всего.Таким образом, вам не нужно всегда создавать 3 похожих объекта только потому, что это «Путь» или всегда пропускать сущности на всем пути до пользовательского интерфейса.Но то, что вам нужно будет , - это четко разделить контексты и определить, какой подход будет использоваться.
В 80% вы, вероятно, получите что-то простое (например, WCF DataServices), и вам не нужно ничего делать, и это хорошо, так как во многих операциях вы просто хотите изменить данные.
Но в других 20% (которые являются «ядром» вашего приложения), где живет настоящая бизнес-логика, - здесь вы можете захотеть такого рода разделения не только для объектов, но и для обязанностей между вашими уровнями..