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

Question

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

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

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

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

Полагаю, я спрашиваю:

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

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

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

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

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

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

Answer 1

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

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

Answer 2

Вы перечислили следующие проблемы:

---

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

---

вот мой дубль:

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

Чтобы решить проблему технического обслуживания конфигурации приложения, существуют некоторые стандарты, такие как 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 8

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

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

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