Что мне не хватает в WCF?

Question

Я развивался в технологиях MS дольше, чем я должен помнить на этом этапе. Когда .NET прибыла на сцену, я подумал, что они наткнулись на гвоздь на голове, и с каждой итерацией и версией я думал, что их технологии становятся все сильнее и сильнее и с нетерпением ждут каждого релиза.

Однако, поскольку мне пришлось работать с WCF в прошлом году, я должен сказать, что мне очень сложно работать и понимать технологию. Первоначально это довольно привлекательно, но когда вы начинаете вникать в это, конфигурация - это кошмар, который должен переопределять поведение для размеров сообщений, количество объектов, содержащихся в сообщениях, сложность модели безопасности, удаление доверенных лиц при сбое и, наконец, возвращаясь к определению интерфейсов в коде, а не в XML.

Он просто не работает из коробки, и я думаю, что это должно произойти. Мы обнаружили все вышеперечисленные проблемы, одновременно проверяя себя или когда наши продукты были на месте.

Я понимаю обоснование всего этого, но, безусловно, они могли бы придумать более простой механизм реализации.

Я полагаю, что я спрашиваю,

• Могу ли я смотреть на WCF неправильный путь?
• Какие сильные стороны он имеет по сравнению с альтернативами?
• При каких обстоятельствах я должен использовать для использования WCF?

OK Folks, К сожалению о задержке в реагировании, работа имеет неприятную привычку мешать иногда :)

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

1. Размер строки, чем может быть передано не может быть более 8K
2. Количество объектов, которые могут быть переданы в одном сообщении ограничено
3. Прокси не автоматически восстанавливаются после сбоев.
4. Объем конфигурации в то время как есть хорошая вещь, но она понимает все и что использовать то, что и при каких обстоятельствах может быть трудно понять. Особенно при развертывании программного обеспечения на сайте с различными требованиями безопасности и т. Д. Когда мы говорим о конфигурации, нам приходилось скрывать многие из них во внутренней базе данных, так как пользователи безопасности и сети на месте пытались изменить ситуацию в файлах конфигурации без понимания Это.
5. Сохранение конфигурации интерфейсов в коде, а не переход к явно определенным интерфейсам в XML, которые могут быть опубликованы и использованы практически любым способом. Я знаю, что мы можем экспортировать XML из сборки, но он полна мусора, и некоторые генераторы кода задыхаются.

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

Я просто думаю, что должны быть более простые параметры конфигурации/развертывания, более простая настройка и лучшее управление конфигурацией (возможно, поставщик конфигурации SQL, а не только файлы web.config/app.config).

Answer 1

После разъяснения я рассмотрю оставшиеся вопросы. Тем временем я могу ответить на ваш вопрос, когда вы должны использовать WCF: всегда.

WCF является заменой для старых технологий ASMX, включая WSE. Это также замена .NET Remoting. Это единственная технология, на которой высокоуровневые функции связи в .NET будут основываться на обозримом будущем.

Например, рассмотрите Windows Azure. Не исключено, что новая концепция «облачных вычислений» будет иметь свои коммуникационные аспекты, охватываемые WCF. Тем не менее, WCF был достаточно гибким, чтобы быть расширенным, чтобы охватить эти случаи, с очень небольшим изменением кода.

Если у вас возникли проблемы с WCF, вам следует убедиться, что Microsoft знает об этом. WCF - это настоящее и будущее веб-сервиса и других сервис-ориентированных разработок в .NET, поэтому у них есть очень сильный стимул слушать вас и решать ваши болевые точки. Либо свяжитесь с ними напрямую через Connect, либо задайте вопросы здесь, на SO (тег с WCF, пожалуйста), и многие люди вам помогут.

Answer 2

Я использую WCF все время, и я разделяю вашу боль. Похоже, что это было сильно переработано, но мы собираемся застрять с ним в течение долгого времени, поэтому я пытаюсь это изучить.

Одно я уверен, что XML отстой. У меня не было ничего, кроме проблем с использованием XML для управления им, и с тех пор я переключился на обработку всего кода.

Answer 3

Рассматривая, как вы упоминаете XML и SQL, вы используете WCF для создания веб-приложения или фактического веб-сервиса (услуга в Интернете, а не только обмен SOAP).

Это помогает думать о WCF в качестве замены для .NET Remoting (или DCOM, CORBA и т. Д.), Что также происходит для поддержки веб-сервисов как одного из транспортов. Интерфейсы, объявленные в сборках, поведение прокси, некоторые параметры конфигурации и другие аспекты структуры, которые выглядят неестественными и сложными с точки зрения веб-приложений, действительно работают из коробки для систем распределенных объектов типа DCOM.

Чтобы ответить на вопрос: нет, вы ничего не пропускаете, и использование WCF для веб-приложений является сложным, поскольку WCF не является основой для создания веб-приложений. Вероятно, такая структура может быть построена поверх нее, но мне бы очень хотелось, чтобы WCF сам изменился, чтобы перейти в веб-сферу.

Answer 4

Для решения проблемы сохранения кошмара конфигурации приложения существуют некоторые стандартные, например UDDI или WS-Discovery, WS-Discovery будет поддерживаться WCF в .NET 4.0.

Сохраняя конфигурацию интерфейсов в коде, а не перемещение явно определенные интерфейсы в XML, который может быть опубликован и потребленной почти все. Я знаю, что мы можем экспортировать XML из собрания, , но он полон мусора, и некоторые генераторы кода дросселируют его.

Можете ли вы быть более явным? Я думаю, вы говорите о поведении службы, настроенном в коде. Вы можете легко кодировать расширения поведения, чтобы настроить то, о чем вы говорите, в файле конфигурации вместо кода. Но я думаю, что если бы Microsoft не делала этого, есть веская причина. Например, услуга с таким поведением:

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, ConcurrencyMode=ConcurrencyMode.Single)] 

Реализация знает, что экземпляр не разделяется между несколькими нити так он разработан иначе, чем:

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)] 

В этом случае реализация сервиса должны заботиться о проблемах с соглашением. Реализация связана с атрибутом ServiceBehavior, поэтому перемещение этого поведения в XML-файле не является хорошей идеей.

Что делать, если вы можете изменить службу InstanceContextMode.PerCall на службу InstanceContextMode.Single внутри файла конфигурации? Вы нарушаете приложение!

Answer 5

Озабоченность вы перечислили были:

---

1. Размер строки, чем может быть передано не может быть более 8K
2. Количество объектов, которые могут быть переданы в одном сообщении ограничено
3. Прокси не автоматически восстанавливаются после сбоев
4. Размер конфигурации в то время как есть хорошая вещь, но она понимает все и что использовать то, что и при каких обстоятельствах может быть d трудно понять. Особенно при развертывании программного обеспечения на сайте с различными требованиями безопасности и т. Д. Когда мы говорим о конфигурации, нам приходилось скрывать многие из них во внутренней базе данных, так как пользователи безопасности и сети на месте пытались изменить ситуацию в файлах конфигурации без понимания Это.
5. Сохранение конфигурации интерфейсов в коде, а не переход к явно определенным интерфейсам в XML, которые могут быть опубликованы и использованы практически любым способом. Я знаю, что мы можем экспортировать XML из сборки, но он полна мусора, и некоторые генераторы кода задыхаются.

---

вот мое взятие:

(1) на имя действительной обеспокоенности тем, что клиенты имели с ASMX. Это было слишком широко открытое, без возможности легко контролировать его. Ограничение 8k легко снимается, если вы знаете, где искать. Думаю, вы можете считать это неожиданностью, но это скорее одноразовая вещь. Как только вы узнаете об этом, вы можете поднять его и сделать с ним навсегда, если вы выберете.

(2) также настраивается.

(3) известен, но есть шаблонные способы обойти это. Например, код StockTrader демонстрирует проверенный шаблон. Вы можете повторно использовать код в своем приложении. Не уверен, что это исправлено в WCF для .NET 4.0. Я знаю, что это был открытый запрос.

(4) Конфигурация - это зверь. Это вызывает озабоченность у многих людей. Проблема здесь в том, что WCF настолько гибкий, и конфигурация всей этой гибкости раскрывается через XML-файлы. Это может быть подавляющим. Подход, который, кажется, работает, - это взять его в маленьких укусах, как вам это нужно.

(5) Я не понимаю.

Answer 6

Наибольшее преимущество использования WCF с точки зрения программиста: отделяет определение открытых сервисов (операций, контрактов и т. Д.) От конкретных деталей протокола, в отличие от ASMX, где вы публикуете класс как веб-службу непосредственно в код с использованием атрибутов. Используя настоящий мой пример: мы можем легко переключать транспортный протокол между веб-службами и именованными каналами, независимо от того, что лучше подходит для развертывания и производительности, без изменения строки кода.

Answer 7

WCF предназначен для методологий SOA. Работа, профессионально использующая его, - это кошмар. Я поставил SOA-решение, используя WCF как инструмент и ад, сотни конфигураций и скрытых подсказок! Мое прошлое распределенное решение с использованием старых веб-сервисов и удаленных приложений было более стабильным. Я потратил дни на разработку решения для ошибки «Основное соединение было закрыто: произошла непредвиденная ошибка», что не имеет смысла для одного метода среди 4 в том же контракте. Я очень разочарован. Это заняло меня во времени, когда .net был впервые представлен с множеством обещаний, и когда мы получили руки, черт, проблемы журнала возникли!

Answer 8

Я очень предпочитаю ASP.NET MVC и веб-API через WCF. Если бы мне пришлось обобщить WCF на разработчика, который только что был представлен на нем, я бы сказал: «WCF - это хорошо продуманная попытка заменить чрезмерно спроектированную разработку RPC в стиле Java EE». К сожалению, многие принятые решения требуют от вас стать экспертом в настройке низкоуровневых, несущественных элементов (размеров сообщений, тайм-аутов, неинтересных элементов протокола и т. Д.), В то время как абстрагирование абсолютно критических частей (дизайн URL, сериализация параметров, сериализация ответа и т. Д.).). Разница в производительности и обострении между командами, которые я знаю с помощью WCF vs. Web API, - это ночь и день.

Чтобы немного поправиться: я всегда ненавидел основную концепцию .NET Remoting. Я считаю, что разработчикам необходимо всестороннее понимание структуры ресурсов своего приложения и как эти ресурсы сериализуются. Кроме того, использование глагола «POST» для простого извлечения данных вызывает тревогу при чтении тяжелого приложения, которое необходимо масштабировать.