Определение DataContract для универсальных классов - PullRequest
1 голос
/ 16 января 2012

У нас есть многоуровневое приложение:

UI <-> WCF <-> DAL (с использованием каркаса сущностей)

Мы не хотим показывать наши EntityTypes, поэтому мы конвертируем в пользовательские DTO в DAL. На типы DTO ссылаются решения UI, WCF и DAL.

Поднята пара вопросов -

  • Существуют ли какие-либо негативные последствия добавления атрибутов [DataContract] и [DataMember] ко всем нашим типам и свойствам пользовательских DTO?
  • Может ли это вызвать какие-либо проблемы в приложениях, которые не хотят получать доступ к данным через WCF?

Ответы [ 2 ]

2 голосов
/ 16 января 2012

Нет и нет. Эти атрибуты являются частью механизма, который WCF использует для создания и реализации вашего контракта с веб-сервисом и определения того, что сериализуется по сети или нет.

0 голосов
/ 01 декабря 2012

Атрибуты вставляются в метаданные и хранятся там до тех пор, пока некоторый пользовательский код не запросит их, используя отражение.Они не влияют на производительность, единственное, что они увеличивают таблицы метаданных сборки.Но это больше проблема дизайна, обычно вы не должны были попадать в этот сценарий.Если вы украсите некоторый класс атрибутом, независимым от платформы, таким как [Serializable], то вы скажете: «Хорошо, этот тип может быть сериализован однажды, независимо от того, как и где вы хотите его использовать».И это довольно хорошо, но если вы украсите тот же класс атрибутом для конкретной платформы, таким как [DataContract], то вы как бы говорите миру: «Хорошо, это DTO WCF и предназначено для использования в работе».контракты».Кроме того, вы связываете класс с DataContractSerializer и даже больше, если вы используете DataContract, то вам также нужно явно определить [DataMember] s.

Вывод - обычно вы не должны были идти этим путем,Подумайте о рефакторинге вашей модели программного обеспечения.

...