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

#.net #wcf #default-value #datacontract

#.net #wcf #значение по умолчанию #datacontract

Вопрос:

Я уже некоторое время работаю с WCF и в тех местах, где клиент и сервер, как правило, выпускаются совместно; то есть новые версии почти всегда выпускались одновременно. Совместимость и управление версиями не являются проблемами (по крайней мере, в этом случае).

Документация MSDN, DataMemberAttribute .Управление версиями EmitDefaultValue и Data Contract предполагает, что использование значения по умолчанию является плохой практикой, если нет особой необходимости и поддержки управления версиями.

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

Есть ли какие-либо другие причины, по которым этого следует избегать?

Ответ №1:

Я также использую DataMemberAttribute.EmitDefaultValue = false в некоторых местах, чтобы попытаться ограничить объем передаваемых данных. В моем случае я контролирую как клиентскую, так и серверную части, поэтому у меня нет никаких проблем с этим.

Я нашел ссылку на потенциальный конфликт с DataMemberAttribute.IsRequired , о котором я раньше не знал:

Требуется взаимодействие с

…Если для параметра IsRequired установлено значение true (что указывает на то, что значение должно присутствовать), а для параметра EmitDefaultValue установлено значение false (что указывает на то, что значение не должно присутствовать, если для него установлено значение по умолчанию), значения по умолчанию для этого элемента данных не могут быть сериализованы, поскольку результаты будут противоречивыми. Если для такого элемента данных установлено значение по умолчанию (обычно null или ноль) и предпринимается попытка сериализации, генерируется исключение SerializationException .

Обычно это не должно быть проблемой, потому что, как только вы пытаетесь сериализовать объект с элементом, помеченным EmitDefaultValue = false , IsRequired = true , и значением по умолчанию, вы получаете SerializationExeception , так что проблема очень очевидна (я только что проверил это). Тем не менее, я мог видеть ситуации, когда значение EmitDefaultValue is false и в более позднее время IsRequired установлено на true , создавая проблемы (надеюсь, это было обнаружено при тестировании до развертывания изменения).

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

Все это, как говорится, я думаю, что вы используете настройку по конкретным причинам, указанным в документации. Просто имейте в виду потенциальный конфликт с. IsRequired

Комментарии:

1. Мне кажется, что есть смысл установить IsRequired=true и EmitDefaultValue=false . Для примитивных типов или DateTime это не позволит клиенту передавать значения по умолчанию, когда они действительно должны устанавливать значение, отличное от значения по умолчанию. Это избавляет вас от необходимости проверять значения по умолчанию на стороне сервера, что, я не думаю, является чистым способом проверки значений.