WCF піднімає планку або просто рівень складності? [зачинено]

Я розумію цінність моделі із трьох частин служби / хосту / клієнта, запропонованої WCF. Але це лише я, чи здається, що WCF взяв щось досить пряме і прямолінійне (модель ASMX) і зробив із цього безлад?

Чи існує альтернатива використанню кроку командного рядка SvcUtil назад у часі для створення проксі-сервера? З послугами ASMX тестовий джгут був автоматично наданий; чи є сьогодні хороша альтернатива WCF?

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

Крім того, стан книг, доступних для WCF, у найкращому випадку страшний. Джуваль Лоуі, чудовий автор, написав хороший довідник О'Рейлі "Програмування служб WCF", але це не так багато (для мене в будь-якому випадку) для того, щоб навчитися користуватися WCF зараз. Попередником цієї книги (і трохи краще організованим, але не набагато, як підручник) є навчальний WCF Мікеле Леру Бустаманте. Він має хороші місця, але застарів, і відповідний веб-сайт зник.

Чи є у вас хороші посилання на вивчення WCF, крім того, що ви просто продовжуєте шукати Google у бежевій формі?

Гаразд, ось ми йдемо. По-перше, книга Мікеле Леру Бустаманте була оновлена ​​для 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 (наприклад, переписування підписів методів при виставленні послуги через базовий HTTP - дивіться тут , але загалом я думаю, що це певне вдосконалення

Якщо ви використовуєте VS2008 і створюєте проект WCF, тоді ви автоматично отримуєте тестовий джгут, коли натискаєте run / debug, і ви можете додати посилання без використання 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
• Фундамент як послуга WCF. Додаток Silverlight для опитування a
• послуга для останніх каналів даних.

Особливості WCF

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

джерело: основне джерело тексту

MSDN? Зазвичай я досить добре працюю з самою бібліотекою, і я зазвичай сподіваюся знайти там цінні статті.

Щодо того, що він пропонує, я думаю, що відповідь - сумісність. Послуги ASMX були досить Microsofty. Не сказати, що вони не намагалися бути сумісними з іншими споживачами; але модель не була розроблена так, щоб вміщатись крім веб-сторінок ASP.NET та деяких інших користувацьких споживачів Microsoft. Тоді як WCF, завдяки своїй архітектурі, дозволяє вашій службі мати на додаток до звичайного SOAP кінцеві точки на основі відкритого стандарту, наприклад REST, JSON тощо. Іншим людям, напевно, буде набагато легше витратити час на послугу WCF, ніж послуга ASMX.

(Це все випливає в основному з порівняльного читання MSDN, тому той, хто знає більше, повинен сміливо мене виправляти.)

WCF не слід розглядати як заміну ASMX. Судячи з того, як вона позиціонується і як вона використовується внутрішньо корпорацією Майкрософт, це справді фундаментальна частина архітектури, яка використовується для будь-якого типу транскордонного зв'язку.

Я вважаю, що 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.)