Entity Framework и DTO

Im планирует использовать сущности, созданные EF (POCO) при отправке данных клиенту вместо создания DTOs? Это хорошая практика? В принципе, мой файл EDMX находится на моем слое DAL. Таким образом, пользовательский интерфейс будет иметь прямой доступ к моему DAL. Спасибо.

9
c# dto

5 ответов

в принципе, я не думаю, что это хорошая идея отправить объекты DAL в ваш интерфейс, поэтому я бы использовал DTOs. Чтобы свести к минимуму усилия, я бы посмотрел на генератор DTO, для генерации кода DTO, который позволяет конвертировать из объекта DAL в DTO и наоборот.

EDIT: извините, не видел, что вы используете POCO. Взгляните на это так пост

10

Это зависит от того, насколько близко клиент к домену объекта. Если это клиент, тогда может быть - и действительно это в значительной степени, как ADO.NET работа служб Data Services (etc) - прямое отображение вашей модели.

однако, если клиент все остальное Я бы предложил специальный DTO. На самом деле, я бы предложил это в любом случае ;p в противном случае, это становится несколько сложным:

  • управление деталями сериализации (какие члены? какие имена? что? случается, когда мы его пересказываем?)
  • обработка свойств отношения (it и an Orders член... но разве он лениво заряжен? хотим ли мы этого?)
  • объединение входящих объектов (для обновлений и т. д.) обратно в модель
  • подавление любой логики, добавленной в сеттеры и т. д., Во время десериализации
  • управление идентификацией при получении 2 отдельных копий одного и того же объекта в древовидном сериализаторе, например DataContractSerializer

в большинстве случаев наличие отдельного DTO делает большинство этих проблем просто уйти

10

прежде всего, я считаю, что вы не можете использовать сущности, созданные Entity Framework в качестве возвращаемых типов в вашей службе, по крайней мере, в Службе WCF.

но почему вы хотите использовать сущности во всем своем приложении? Если у вас есть общая архитектура со структурой клиент-сервер, вашему клиенту не понадобится вся информация, которую имеет EntityObject, например ObjectContext, где он содержится, состояние на нем и много другой информации, которую ваш клиент не только не будет использовать, но и что еще важнее: не нужно знать.

в этом случае вы должны использовать шаблон DTO или другой шаблон дизайна, который, по вашему мнению, лучше отделяет серверную сторону от клиентской. Я считаю, что шаблон DTO наиболее широко используется и рекомендуется. Если вы используете Entity Framework, вы можете перейти кhttp://entitiestodtos.codeplex.com, это и AddIn для Visual Studio, который я опубликовал, это бесплатно и с открытым исходным кодом. Он генерирует DTOs из модели данных Entity Framework (Edmx в).

с уважением, Фабиан Фернандес!--1-->

1

DTO является хорошей практикой для минимизации объема данных, которые вы передаете по проводу, чтобы включать только соответствующие поля. Это среди других преимуществ. Checkout Automapper и метод ProjectTo, который может автоматически конвертировать DAL в DTO и наоборот. ProjectTo под капотом будет выбирать только столбцы, включенные в настроенное сопоставление.

https://github.com/AutoMapper/AutoMapper/wiki/Queryable-Extensions

1

использование кода Entity Framework сначала TT, например " генератор обратного POCO EntityFramework" (https://marketplace.visualstudio.com/items?itemName=SimonHughes.EntityFrameworkReversePOCOGenerator) создание бизнес-моделей, связанных со схемой таблиц базы данных в отдельной библиотеке моделей бизнес-сущностей. TT может быть изменен, чтобы включить пользовательские атрибуты (такие как DataMember, Serializable) специально для сущности WCF.

этот путь смог иметь оба преимущества DTO и EF POCO. Он может легко поддерживать согласованность между объектами бизнес-моделей и таблицами базы данных.

причина в том, что в большинстве случаев в любое время измените структуру таблицы базы данных, разработчику также необходимо согласовать структуру бизнес-модели (DTO здесь). Проводятся дополнительные работы по обслуживанию картографов.

Если модель уровня доступа к базе данных (EF POCO здесь) свободная связь с моделью DTO. Разработчику будет очень сложно обнаружить потенциальную ошибку, которая не удается отобразить во время компиляции специально для обслуживания существующих приложений корпоративного уровня.

Если у нас есть дополнительные пользовательские свойства, необходимые для сущностей бизнес-модели, мы можем добавить частичный класс с пользовательскими свойствами.

мы все еще можем использовать картографы для преобразования сущности EF POCO в сущность DTO, когда это необходимо. Но моя точка зрения, попытаться свести к минимуму злоупотребления с помощью картографов, которые просто делают дубликаты работ по сравнению с непосредственно привязкой данных к EF POCO модель.

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

0