WCF поднимает планку или просто уровень сложности?

Трудные вещи, которые я нахожу с WCF, управляют конфигурациями для клиентов и серверов и диагностируют не настолько хорошие неработающие исключения состояния.

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

Я полагаю, что WCF действительно совершенствует реализацию веб-сервисов ASMX во многих отношениях. В первую очередь, это обеспечивает очень хорошую многоуровневую объектную модель, которая помогает скрыть внутреннюю сложность распределенных приложений. Во-вторых, у Вас могут быть больше, чем шаблоны обмена сообщениями воспроизведения запроса, включая асинхронные уведомления от сервера до клиента (невозможный с чистым HTTP), и в-третьих абстракция далеко протокол базовой передачи от обмена сообщениями XML и таким образом изящно поддержки HTTP, HTTPS, TCP и другого. Обратная совместимость с "1-м поколением" веб-сервисы также плюс. WCF использует стандарт XML в качестве внутреннего формата представления. Это могло быть воспринято как преимущество или недостаток, особенно с растущей популярностью "обезжиренные альтернативы XML" как JSON.

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

С точки зрения того, что это предлагает, я думаю, что ответ является совместимостью. Сервисы ASMX были симпатичной Микрорастяпой. Не сказать, что они не пытались быть совместимыми с другими потребителями; но модель не была сделана соответствовать очень помимо веб-страниц ASP.NET и некоторых других пользовательских потребителей Microsoft. Принимая во внимание, что WCF, из-за его архитектуры, позволяет Вашему сервису иметь очень открыто-стандартный - базирующиеся конечные точки, например, REST, JSON, и т.д. в дополнение к обычному SOAP. У других людей, вероятно, будет намного более легкое трудоемкое Вашим сервисом WCF, чем Ваш ASMX один.

(Это все в основном выведено из сравнительного чтения MSDN, таким образом, кто-то, кто знает больше, должен не стесняться исправлять меня.)

MSDN? Я обычно делаю вполне прилично с самим Справочным руководством по библиотеке, и я обычно ожидаю находить ценные статьи там.

Мои начальные мысли о WCF были точно тем же! Вот некоторые решения:

1. Программируют Ваши собственные дженерики использования слоя прокси/клиента (см. классы ClientBase, Связывая). Я нашел это легким получить работу, но трудно к идеальному.
2. Использование сторонняя реализация 1 ( SoftwareIsHardwork является моим текущим фаворитом)

Если Вы используете VS2008 и создаете проект WCF тогда, Вы автоматически получаете тестовую обвязку, когда Вы совершаете нападки выполненный/отлаженный, и можно добавить ссылку, не имея необходимость использовать svcutil.

VS2008 включает объект контекстного меню "Add Service Reference", который создаст прокси для Вас негласно.

, Как был упомянут ранее, WCF не предназначается только как замена для типов веб-сервиса ASMX, но предоставлять последовательную, безопасную и масштабируемую методологию всем совместимым сервисам, является ли это по HTTP, tcp, именованным каналам или транспортам MSMQ.

я признаюсь, что у меня действительно есть другие проблемы с WCF (например, переписывающий сигнатуры методов, когда представление сервиса по basicHTTP - видит здесь , но в целом я думаю, что это - определенное улучшение

Я не вижу, что это упоминало достаточно часто, но Вы можете все еще реализовывать довольно простые сервисы с WCF, очень похожим на сервисы ASMX. Например:

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
    [OperationContract]
    public string HelloWorld()
    {
        return "Hello World";
    }

}

все еще необходимо зарегистрировать конечную точку в web.config, но это не так плохо.

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

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

WCF намного более мощен, чем ASMX, и это расширяет его несколькими способами. ASMX ограничен только HTTP, тогда как WCF может использовать несколько протоколов для своей коммуникации (предоставленный, HTTP является все еще способом, которым большинство людей будет использовать его, по крайней мере, для сервисов, которые должны быть совместимыми). WCF также легче расширить. По крайней мере, возможно расширить его способами, которыми не может быть расширен ASMX. "Легкий" может расширять его. =)

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

У меня есть трудное время для наблюдения, когда я должен или использовать WCF. Почему? Поскольку я поместил производительность и простоту сверху моего списка. Почему модель ASMX была так успешна, потому что она работала, и Вы заставляете ее работать быстро. И с VS 2005 и.NET 2,0 wsdl.exe выкладывал довольно хорошие и совместимые сервисы.

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

Я обычно использую Google, чтобы найти мои ответы WCF и обычно оказываться на следующих блогах:

Блоги с ценными статьями WCF

• http://blogs.msdn.com/drnick/default.aspx
• http://blogs.msdn.com/wenlong/default.aspx
• http://blogs.thinktecture.com/buddhike/
• http://www.dasblonde.net/default.aspx

Другие ценные статьи я нашел

• http://blogs.conchango.com/pauloreichert/archive/2007/02/22/WCF-Reliable-Sessions-Puzzle.aspx
• http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx

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

WCF также по умолчанию разрешает подключаться к службе только 1 или 2 клиентам, пока вы не измените большую часть конфигурации. Изменить конфигурацию из кода непросто, доставка большого количества файлов comfig не является вариантом, так как слишком сложно объединить наши изменения с любыми изменениями, которые клиент мог сделать во время обновления (также мы не хотим, чтобы клиенты играть с настройками WCF!)

Удаленное взаимодействие .NET обычно просто работает большую часть времени.

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

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