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

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

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

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

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

Я предполагаю, что я прошу,

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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

вот мой прием:

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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