Как лучше всего отправлять данные клиенту: POCO или DTO?

Question

Я начинаю проект, используя EF 4 и POCO.

Как лучше всего отправлять данные клиенту?Должен ли я отправлять POCO или вместо него должен быть DTO?

Есть ли какие-либо проблемы, о которых мне следует знать при отправке объекта (который отключен от контекста) клиенту?

Рекомендуется ли отправлять POCO на уровень клиента?

Answer 1

Я считаю, что мы смешиваем здесь 2 определения, которые не имеют отношения друг к другу.

DTO или Data Transfer Object - это шаблон проектирования, вы можете использовать его для передачи данных между слоями, а также они не имеют поведения. Мартин Фаулер очень хорошо объясняет это по адресу: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

В другой руке у нас есть POCO или Plain Old CLR Object. Но чтобы говорить о POCO, мы должны знать, с чего он начался, то есть POJO или Plain Old Java Object. Мартин Фаулер с двумя партнерами придумал этот термин, и он объясняет его здесь: http://www.martinfowler.com/bliki/POJO.html

Так что POCO могут иметь поведение и все, что вы хотите. Это те же самые общие классы, которые вы пишете в своей повседневной жизни, они просто дали им это имя, чтобы кратко и легко запомнить их.

В ответ на ваш второй вопрос, я думаю, что лучший подход, и я всегда обращаюсь к нему, это отправка DTO из уровня Busines на все, что его использует (например: ваши сервисы, веб-сайт, настольное приложение, мобильное приложение и т. Д.) .). Это связано с тем, что в большинстве случаев они не имеют поведения и не только свойств, поэтому они легковесны и идеально подходят для использования в службах, и, конечно, они не раскрывают конфиденциальные данные вашего бизнеса.

При этом, если вы планируете использовать DTO, я могу порекомендовать вам скачать EntitiesToDTOs, Entity Framework DTO Generator, который я недавно опубликовал в CodePlex, он бесплатный и с открытым исходным кодом. Перейти к http://entitiestodtos.codeplex.com

Answer 2

Для меня одной из главных причин использования EF4 с POCO является тот факт, что вам не нужно DTO.Я понимаю, как использовать DTO с традиционными файлами EDMX, где ваши сущности довольно раздуты, но это не так.

Очевидно, что ваш POCO должен быть сериализуемым, но на самом деле не должно быть никаких проблем, специфичных для отправкиОбъекты POCO, которые также не встречаются с DTO.

Answer 3

У меня немного другое мнение из вышеупомянутых мнений.Я считаю, что DTO или ViewModel все еще необходимы для внешней стороны уровня сервера.В реальных приложениях существует несколько слоев представления, для которых нужен только один объект домена, то есть почти каждому представлению требуется несколько объектов домена.И все эти доменные объекты заключены в один класс DTO или ViewModel.Вот почему я настаиваю на том, что DTO или ViewModel по-прежнему необходимы, даже если они POCO.

Answer 4

Я бы рассмотрел бизнес-модели сущностей EF4 И модели представлений в одном лице.Например, они уже реализуют PropertyChanged из коробки.Частичные классы могут предоставить пользовательские функции, если вам нужно.По моему мнению, зеркальное отображение объектов с собственным уровнем безопасности создает ненужную работу и обслуживание.

Я верю в разделение бизнес-логики и всего остального.Однако в случае EF4 работа уже сделана для вас.Офигеть.