Я запускаю проект с использованием EF 4 и POCO.
Какова наилучшая практика отправки данных клиенту? Должен ли я отправлять POCO, или вместо этого у меня должен быть DTO?
Есть ли какие-либо проблемы, о которых мне следует знать при отправке объекта (который отключен от контекста) клиенту?
Рекомендуется ли отправлять POCO на клиентский уровень?
Для меня одной из основных причин использования EF4 с POCO является то, что вам не нужны DTO. Я могу понять, используя DTO с традиционными файлами EDMX, где ваши объекты довольно раздуты, но это не так.
Очевидно, что ваш POCO должен быть сериализуемым, но действительно не должно быть никаких проблем, связанных с отправкой объектов POCO, которые также не встречаются с DTO.
Я считаю, что мы смешиваем 2 определения здесь, которые не имеют отношения друг к другу.
DTO или объект передачи данных - это шаблон проектирования, вы можете использовать его для передачи данных между слоями, а также не иметь поведения. Мартин Фаулер очень хорошо объясняет это: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html
С другой стороны, у нас есть объект POCO или обычный объект CLR. Но чтобы поговорить о POCO, мы должны знать, с чего это началось, то есть POJO или обычный Java-объект Plain. Мартин Фаулер с двумя партнерами придумал термин, и он объясняет это здесь: http://www.martinfowler.com/bliki/POJO.html
Таким образом, POCOs могут иметь поведение и все, что вы хотите. Это те же самые общие классы, которые вы пишете в повседневной жизни, они просто дали им такое имя, чтобы называть их коротким и легко запоминающимся способом.
В ответ на ваш второй вопрос, я думаю, что лучший подход и тот, который я всегда использую, - это отправлять DTO из уровня Busines на все, что его использует (например: ваши службы, веб-сайт, настольное приложение, мобильное приложение и т.д..). Это связано с тем, что в большинстве случаев у них нет поведения, а не только свойств, поэтому они легки и идеально подходят для использования в сервисах, и, конечно же, они не раскрывают конфиденциальных данных из вашего бизнеса.
Если вы планируете использовать DTO, я могу порекомендовать вам загрузить EntitiesToDTOs, генератор DTO Entity Framework, который я недавно опубликовал в CodePlex, он является бесплатным и открытым исходным кодом. Перейдите к http://entitiestodtos.codeplex.com
У меня есть немного другое мнение, исходящее из мнений. Я считаю, что DTO или ViewModel по-прежнему необходимы для внешней стороны уровня сервера. В приложении реального мира существует несколько уровней представления, которым нужен только один объект домена, то есть почти для каждого представления требуется несколько объектов домена. И все эти объекты домена обернуты в один класс DTO или ViewModel. Вот почему я настаиваю на том, что DTO или ViewModel все еще нужны, даже если они POCO.
Я бы рассмотрел бизнес-модели сущностей EF4, а viewmodels - в один. Например, они уже реализуют PropertyChanged из коробки. Частичные классы могут предоставлять пользовательские функции, если вам нужно. На мой взгляд, зеркальное отображение объектов с помощью собственного уровня безопасности создает ненужную работу и обслуживание.
Я сторонник разделения бизнес-логики и всего остального. Однако в случае EF4 работа уже выполнена для вас. Идите гайки.