Поднимает ли WCF планку или просто уровень сложности? [закрыто]

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

Есть ли альтернатива использованию шага назад во времени в командной строке SvcUtil для создания прокси? Для сервисов ASMX автоматически предоставлялась тестовая оснастка; есть ли сегодня хорошая альтернатива WCF?

Я ценю, что материал WS * более тесно интегрирован с WCF, и надеюсь найти в нем некоторую отдачу от WCF, но блин, иначе я озадачен.

Кроме того, состояние книг, доступных для WCF, в лучшем случае ужасно. Джувал Лоуи, превосходный автор, написал хороший справочник О'Рейли «Программирование служб WCF», но он не так уж много (по крайней мере для меня) для обучения использованию WCF. Предшественником этой книги (и немного лучше организованной, но не намного, как учебное пособие) является Learning WCF Мишеля Леру Бустаманте. У него есть хорошие места, но он уже давно устарел, и соответствующий ему веб-сайт больше не существует.

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

Хорошо, поехали. Во-первых, книга Мишель Леру Бустаманте была обновлена ​​для VS2008. Веб-сайт книги не исчез. Он запущен прямо сейчас, и в нем есть масса отличной информации о WCF. На этом веб-сайте она предоставляет обновленный код, совместимый с VS2008, для всех примеров в ее книге. При заказе на Amazon вы получите обновленную копию.

WCF - это не только замена ASMX. Конечно, он может (и неплохо работает) заменить ASMX, но реальное преимущество заключается в том, что он позволяет размещать ваши сервисы самостоятельно. Большая часть функциональности WSE заложена с самого начала. Фреймворк легко настраивается, и способность обслуживать несколько конечных точек по нескольким протоколам просто потрясающая, IMO.

Хотя вы все еще можете создавать прокси-классы с помощью параметра «Добавить ссылку на службу», в этом нет необходимости. Все, что вам действительно нужно сделать, это скопировать интерфейс ServiceContract и указать своему коду, где найти конечную точку для службы, и все. Вы можете вызывать методы из службы с очень небольшим кодом. Используя этот метод, вы получаете полный контроль над реализацией. Независимо от того, какой метод вы выберете для создания прокси-класса, Мишель показывает оба и использует их в своей прекрасной серии веб-трансляций по этой теме.

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

• Интернет-трансляции Мишель: http://www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx
• Сайт книги Микеле (жив и обновлен для VS2008): http://www.thatindigogirl.com/

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

Я обычно использую 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

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

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

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

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

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

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

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

}

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

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

VS2008 включает в себя пункт контекстного меню «Добавить ссылку на службу», который за кулисами создаст для вас прокси.

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

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

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

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

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

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

«Веб-службы» WCF являются частью гораздо более широкого спектра удаленного взаимодействия, обеспечиваемого через WCF. Вы получите гораздо более высокую степень гибкости и переносимости, выполняя действия в WCF, чем при использовании традиционного ASMX, потому что WCF с самого начала спроектирован для обобщения всех различных инфраструктур распределенного программирования, предлагаемых Microsoft. Конечная точка в WCF может передаваться через SOAP / XML так же легко, как и через TCP / двоичный, и для изменения этого носителя достаточно просто изменить файл конфигурации. Теоретически это уменьшает количество нового кода, необходимого при переносе или изменении бизнес-потребностей, целей и т. Д.

ASMX is older than WCF, and anything ASMX can do so can WCF (and more). В принципе, вы можете рассматривать WCF как попытку логически сгруппировать вместе все различные способы взаимодействия двух приложений в мире Microsoft; ASMX был лишь одним из многих способов, поэтому теперь он сгруппирован в рамках возможностей WCF.

Доступ к веб-службам можно получить только через HTTP, и он работает в среде без сохранения состояния, где WCF является гибким, поскольку его службы могут размещаться в различных типах приложений. Распространенными сценариями размещения служб WCF являются IIS, WAS, самостоятельный хостинг, управляемая служба Windows.

Основное отличие состоит в том, что веб-службы используют XmlSerializer. Но WCF использует DataContractSerializer, который лучше по производительности по сравнению с XmlSerializer.

В каких сценариях необходимо использовать WCF

• Безопасный сервис для обработки бизнес-транзакций. Сервис, который
• предоставляет текущие данные другим, такие как отчет о трафике или другие
• служба мониторинга. Сервис чата, который позволяет двум людям
• общаться или обмениваться данными в режиме реального времени. Приложение приборной панели
• который опрашивает одну или несколько служб на предмет данных и представляет их в логическом
• презентация. Представление рабочего процесса, реализованного с помощью Windows Workflow
• Foundation как служба WCF. Приложение Silverlight для опроса
• сервис для последних каналов данных.

Особенности WCF

• Сервисная ориентация
• Совместимость
• Несколько шаблонов сообщений
• Метаданные службы
• Контракты данных
• Безопасность
• Множественные транспорты и кодировки
• Надежные сообщения и сообщения в очереди
• Долговечные сообщения
• Сделки
• Поддержка AJAX и REST
• Расширяемость

источник: основной источник текста

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

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

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

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

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

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

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

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

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

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

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

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