Что я пропускаю о WCF?

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

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

I'll address the rest of your issues after clarification. In the meantime, I can address your question on when you should choose to use WCF: always.

WCF is the replacement for the old ASMX technologies, including WSE. It is also the replacement for .NET Remoting. It is the only technology upon which high-level communications features in .NET will be based for the forseeable future.

For example, consider Windows Azure. It was not inevitable that the new concept of "cloud computing" would have its communications aspects covered by WCF. Yet, WCF was flexible enough to be extended to cover those cases, with very little change in code.

If you're having trouble with WCF, then you'd do well to make sure Microsoft knows about it. WCF is the present and future of web service and other service-oriented development in .NET, so they've got a very strong incentive to listen to you and resolve your pain points. Either contact them directly through Connect, or ask questions here on SO (tag with WCF, please), and a lot of people will help you.

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

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

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

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

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

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

вот мой вывод:

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

(2) также можно настроить.

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

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

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

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

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