Лучший способ предотвратить передачу неиспользуемых свойств от объекта - PullRequest
4 голосов
/ 21 декабря 2010

Я собираю сервис WCF, который обрабатывает большой поиск (в настоящее время 50-60 параметров, с большей вероятностью, которые будут добавлены в будущем). Для этого у меня есть объект поиска со всеми критериями, которые будут переданы службе в объекте сообщения. Хотя все параметры поиска должны быть доступны, часто бывает так, что 2-3 параметра получают пользовательский ввод, а остальные имеют нулевое значение. На мой взгляд, нет смысла передавать весь объект через каждый метод, если используются только несколько полей. Я ищу метод, который будет извлекать поля, которые используются со своими значениями, которые затем могут быть проверены и переданы на уровень данных для выполнения поиска. Вот несколько способов сделать это, о которых я могу подумать:

  • Используйте отражение, чтобы просмотреть свойства и добавить ненулевые свойства в Dictionary<string, object>. Проблема, которая приходит на ум, заключается в том, что я теряю тип параметра поиска, что означает, что функция поиска на уровне данных будет одним гигантским оператором case с жестко закодированными значениями приведения для каждого потенциального поля. Это кажется излишним и создает слишком тесную связь.
  • Создайте класс SearchValue со свойствами Name, Value и System.Type и используйте отражение для построения List<SearchValue>. Это все еще приводит к большой проверке регистра при поиске, но не по свойству, а по типу. Это имеет некоторую привлекательность в том, чтобы сделать процесс более «общим» (т.е. независимо от того, какая комбинация значений поиска используется), но также создается ощущение, что я заново изобретаю колесо.

Какие плюсы и минусы мне не хватает этих техник? Есть ли лучший способ для достижения моих целей?

Ответы [ 5 ]

0 голосов
/ 27 декабря 2010

Иметь класс dataContract с необязательным датамембером.

[DataMember(EmitDefaultValue = false)]

public int salary = 0;

Сериализатор DataContract игнорирует такой элемент, когда значение по умолчанию.

Рекомендация MSDN: Установка свойства EmitDefaultValue в false не рекомендуется. Это следует делать только в том случае, если в этом есть особая необходимость, например, для обеспечения совместимости или уменьшения размера данных.

У вас также есть свойство IsRequired в DataMember, которое устанавливает его в false и EmitDefaultValue, что помогает сократить издержки транспорта и сериализации.

0 голосов
/ 21 декабря 2010

На ум приходят несколько вариантов:

  • Используйте codegen для создания кода упаковки / распаковки в и из словаря. Код генератора будет использовать отражение, а код упаковки / распаковки - нет.

  • Разделите ваш класс поиска на несколько меньших классов, а затем сделайте так, чтобы ваш класс поиска ссылался на них. Не создавайте экземпляры дочерних классов, если эти параметры поиска не используются. Возможно что-то вроде:

    • Поиск
      • Новый класс, содержащий некоторые общие поля
      • Новый класс, содержащий некоторые другие поля
0 голосов
/ 21 декабря 2010

Я не уверен, что это работает для этой линии связи, но, возможно, свойство EmitDefaultValue в DataMemberAttribute?

0 голосов
/ 21 декабря 2010

В первом пункте вы упомянули использование Reflection для преобразования вашего типа в Dictionary.А с другой стороны, почему бы не написать обратную логику для преобразования Dictionary обратно в ваш тип, используя снова Reflection?

Пример:

Client Side> YourType>> (Reflection) >> Dictionary> Канал> Dictionary >> (Reflection) >> YourType> Server Side

0 голосов
/ 21 декабря 2010

Единственная проблема с передачей всего объекта возможна между клиентом и службой, когда в сериализованном запросе слишком много пустых узлов xml, что делает его больше, чем необходимо. Вы пытаетесь справиться с этим? Я бы сказал, что в любом случае это не имеет большого значения и не стоит изобретать сложные пользовательские механизмы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...