Вы используете перечислимые типы в своих веб-сервисах WCF?
Еще один простой способ перетасовать:
int LengthArray = solutionArray.lenght();
Random r = new Random();
int randomNumber = r.nextInt(LengthArray);
Integer Chosen = solutionArray.getInteger(randomNumber);
7 ответов
Причина, по которой люди рекомендуют избегать перечислений в веб-сервисах, заключается в том, что они создают тонкие, обратно совместимые проблемы.
То же самое относится к обычным перечислениям, но в веб-сервисах проблема еще более ясна, особенно в сгенерированных .NET прокси (см. Ниже).
- Если перечисление вводится только у вас нет проблем.
- Если перечисление может быть параметром out, тогда, если вы добавите новый элемент и вернете его, у старых клиентов могут возникнуть проблемы:
- Если клиент использует прокси-сервер, сгенерированный .NET, он сломается раньше вызывающий может справиться с этим (при десериализации)
- Даже если сгенерированный код для прокси-сервера поддерживает изменение (например, если он отображает перечисление в строку), пользовательский код в клиенте может не обрабатывать новое неожиданное значение (это может быть просто никогда не выполненный путь)
Определяя параметр как строку, вы сигнализируете пользователю вашего API, что значение может измениться в будущем , Даже если вы думаете, что ценность никогда не изменится, это хорошая практика, чтобы быть готовым.
На эту тему есть хороший пост Даре Обасанджо.
Я использовал перечисления в WCF, также в сценариях совместимости. При управлении обеими сторонами сервиса легче работать с. Если Вы только управляете одной стороной сервиса, необходимо высматривать проблемы, которые Вы упомянули.
Перечисления настолько лучше, что строковые переменные, или что еще Вы могли бы принять решение использовать. Используя строки вместо перечислений анти-шаблон, названный "loosey Goosey" в SOA.
Перечисления полностью поддерживаются в WSDL и XSD через xsd:enumeration элемент схемы. Это оказывает поддержку и для единственных значений и для перечислений стиля флагов, где несколько значений в перечислении флагов разделяются пробелами.
, Таким образом, у Вас не должно быть проблемы с помощью перечислений с любыми стандартами совместимые платформы.
Конечно, все это зависит от того, куда Вы собираетесь использовать этот сервис WCF.
, Если это - отдельное приложение, которое будет использовать его, затем изменяя контракт, не будет иметь никаких эффектов.
, Если это - несколько внутренних приложений, изменяя контракт, мог бы потребовать некоторых изменений на других приложениях.
И наконец, если сервис WCF общедоступен, Вам, возможно, придется предоставить 2 версиям сервиса с differents версией так, чтобы у людей, использующих их, было время для передачи их версии клиента в новую службу.
Все это зависит от Ваших потребностей честно.
Я использовал enums в своих сервисах на основе WCF без проблем. Возможные проблемы, о которых вы упомянули, безусловно, следует учитывать, хотя, если вы убедитесь, что применяете перечисления в довольно статичных ситуациях, у вас, вероятно, не будет особых проблем.
Реальная история (значения изменены для анонимности). Используйте, чтобы в приложении было неявное enum
public enum { orange, banana, mango }
Некоторый рефакторинг вокруг порядка и новых значений, и мы решили сделать это явным:
public enum { orange=1, banana=2, grape=3, mango=4 }
выглядит безобидным ...
Следующая вещь, веб-сайт взрывается. Почистите голову, проверьте сервис, добавьте отладочные сообщения, все в порядке.
Вниз по кроличьей норе, один день спустя, причиной является базовый сервис wcf, который использовал enum в качестве возвращаемого типа.
Очевидно, Wcf не любит перечисления без значения по умолчанию .
Исправлено:
public enum { wcfBugBane=0, orange=1, banana=2, grape=3, mango=4 }
Так что ... это может вас укусить.
Перечисления в WSDL должны рассматриваться как забота о техническом обслуживании.
Добавление или удаление значения перечисления является (должно быть!) Триггером для серьезного обновления интерфейса. Если перечисление является выходным значением, то вам обязательно нужно определить новую версию WSDL через новый URI, чтобы текущие клиенты не нарушали установленный контракт («что если они получат одно из этих новых, неожиданных значений в ответ») ? ") Если перечисление является входным значением, вы можете рассматривать это как незначительное обновление (« поскольку текущим клиентам не нужно знать об этом новом значении »), но тогда единственный способ для этих клиентов получить выгоду от добавление этой новой опции / функциональности (вы добавили это новое значение перечисления по какой-то причине, верно?) означало бы попросить их переключиться позже или раньше на новую версию интерфейса.
И это не имеет никакого отношения к функциональному значению enum, я думаю.
Оставайтесь на стороне лучших практик, и вы будете в безопасности.