Чи справді віддалене .NET-програмне забезпечення застаріле?

95

Усі говорять, як .NET Remoting замінюється WCF, але мені цікаво, наскільки це точно. Я не бачив жодного офіційного слова про те, що Remoting припиняє свою діяльність, і мені здається, є, звичайно, сценарії, коли Remoting має більше сенсу, ніж WCF. Жоден з об’єктів або методів, пов’язаних із віддаленням, не застарів, навіть у версії 4.0 фреймворку. Я також розумію, що System.AddIn у фреймворках 3.5 та 4.0 використовує Remoting.

Хтось має якесь офіційне слово про протилежне?

У статті Вибір параметрів спілкування у .NET (для 3.0, оскільки це остання версія цієї статті) зазначено:

8 Зв’язок між доменами між додатками

Якщо вам потрібно підтримувати зв'язок між об'єктами в різних доменах додатків в рамках одного процесу, ви повинні використовувати віддалене управління .NET.

Це, звичайно, не точно, оскільки WCF, безсумнівно, може бути використаний для перетину меж домену додатків, але чи дає це офіційну рекомендацію щодо цього сценарію?

Оновлення: Я надіслав Клеменсу Вастерсу (який був членом команди, що володіє Remoting та WCF) наступне запитання:

Клеменс, я розумію, що ти в команді, яка володіє і віддаленням, і wcf, і у мене є кілька питань, на які, я вважаю, мені потрібно звернутися до джерела.

По-перше, у мене є питання про те, чи не відключається віддалення. Зокрема, у нас є досить великий додаток, який широко використовує віддалене керування для взаємодії між додатками в процесі роботи, і мені було цікаво, чи вважається таке використання віддаленого доступу "спадщиною". Якщо так, чи буде AppDomain.CreateInstance та друзів замінено чимось іншим?

Це його відповідь:

Віддалення є частиною .Net Framework, і як таке воно не зникає. COM був у Windows з Windows NT 3.5 / Windows 95 і нікуди не зник, і я теж не бачу, що це скоро зникне.

Тим не менш, у Remoting є дуже мінімальні інвестиції у розвиток. WCF є наступником Remoting і замінює COM / DCOM для керованого коду.

Віддалене віддалене спілкування в режимі взаємодії між доменами - це рідний спосіб спілкування CLR. Якщо ви стикаєтесь із проблемами продуктивності, які за короткий час перекачують більший обсяг даних або дуже багато повідомлень, вам слід серйозно поглянути на WCF та NetNamedPipeBinding.

.net wcf remoting

— Позначити
джерело

1

Зверніться до stackoverflow.com/questions/1295353/... щодо запитання про те, чому WCF настільки повільніший, ніж Remoting, у моїй конкретній ситуації.

— Марк

1

Віддалення є невід’ємною частиною .NET, а подробиці ролі, яку вона відіграє, та способу її роботи можна знайти в Essential .NET Дона Бокса та Кріса Селса. Однак він розвалюється, коли міжкомпонентний зв’язок ненадійний або повільний, і практично всі транспортні засоби - навіть гігабітний LAN - ненадійні та повільні порівняно з обміном повідомленнями в процесі. Коли люди говорять про те, що WCF повільний, вони зазвичай думають про веб-сервіси. Веб - сервіси є занадто повільно , якщо ви намагаєтеся використовувати їх для в процесі порту зв'язку. Однак вони розроблені для того, щоб переносити повільні та ненадійні зв'язки і добре служити в цих умовах.

— Peter Wone

3

@Peter: дякую за інформацію, але пара ваших припущень абсолютно помилкові. По-перше, віддалення відбувається повільно або ненадійно. Це не. Це дуже швидко і дуже надійно (звичайно, через надійні канали). Іншим є те, що "веб-послуги" (що б це не означало) повільні. Вони ні. Звичайно, все, що знаходиться в процесі, буде набагато швидшим, ніж будь-що через мережу, але це зовсім не те, про що йдеться в цьому питанні ...

— Марк

54

Називати це застарілою технологією є більш точним описом.

http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx

Ця тема стосується застарілої технології, яка зберігається для зворотної сумісності з існуючими програмами і не рекомендується для нової розробки. Тепер розподілені програми слід розробляти за допомогою Windows Communication Foundation (WCF).

Оновлення: WCF не розрізняє між / інтра / процес / інтер / інтра-додатокдомен. Якщо ви використовуєте єдиний машинний зв’язок у WCF, ви використовуєте іменовані канали - використання цього повинно забезпечити хорошу продуктивність практично у всіх реалістичних сценаріях.

Порівняння продуктивності різних розподілених комунікаційних технологій див. Тут .

— RichardOD
джерело

Хіба ця стаття не стосується конкретно використання дистанційного керування в міжпроцесному зв'язку? Мені здається, що віддалене керування все ще має місце у взаємодії між додатками (AppDomain.CreateInstanceFromAndUnwrap та друзі).

— Марк

Так. Якби ці класи були "застарілими", до них застосували ObsoleteAttribute - msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .

— RichardOD

2

@Mark, @RichardOD: Стаття - головна стаття про .NET Remoting. Це стосується не лише міжпроцесорного спілкування. Крім того, той факт, що ObsoleteAttribute відсутній на них у .NET 3.5, нічого не означає, оскільки рішення про оголошення Remoting (та веб-служб ASMX) як "застарілу" було прийнято після .NET 3.5 RTM.

— Джон Сондерс,

@John: Вони також не позначені [Застарілими] в 4.0 (принаймні поки що).

— Марк

@Mark: ви маєте на увазі 4.0 бета-версії 1.

— Джон Сондерс

11

Так. Віддалення застаріло ... і воно офіційне від Microsoft. Ось посилання:

Віддалення .NET

У першому рядку статті жирним шрифтом написано:

Ця тема стосується застарілої технології, яка зберігається для зворотної сумісності з існуючими програмами і не рекомендується для нової розробки. Тепер розподілені програми слід розробляти за допомогою Windows Communication Foundation (WCF).

Я думав, що багатослів'я "застаріло", але, очевидно, вони називають це "спадщиною"

— Джастін Нісснер
джерело

21

ІМО "застарілий" сильніший за "застарілий": "застарілий" означає "не запускати", а застарілий означає "якщо ви вже розпочали, зупиніть зараз, тому що він може бути повністю видалений у наступних версіях".

— ChrisW

1

@Mark: Я не так читаю. WCF здається настільки ж придатним для внутрішньопроцесового зв'язку, як і віддалене (див. NetNamedPipeBinding у WCF).

— Майкл Петротта,

1

@Mark: Незалежно від того, віддалене керування застаріло. @ChrisW: Я сумніваюся, що віддалення буде видалено найближчим часом, але ви можете очікувати менше виправлень помилок, якщо такі є, і менше підтримки, якщо такі є.

— Джон Сондерс,

1

@Mark - яке ваше справжнє запитання? Віддалення вважається застарілою технологією. Здається, ви не хочете, щоб це було правдою. У вас можуть бути вагомі причини, але це насправді не відповідає сучасним рекомендаціям Microsoft.

— Michael Petrotta

1

@ Джон: Здається, я. Я спеціально працюю в процесі взаємодії між додатками (використовуючи AppDomain.CreateInstanceFromAndUnwrap та друзів), і я не бачу способу зробити це так чисто (або як високопродуктивний) за допомогою WCF. Я із задоволенням використовую WCF (я використовую його багато в інших сценаріях), але для цього у мене виникають проблеми з тим, щоб він працював так, як я хочу. Я розміщу ще одне запитання щодо цього конкретного сценарію.

— Марк

6

Якщо ви хочете перейти на .NET Core, вам все одно доведеться знайти інше рішення для віддалення:

Віддалення .NET було визначено як проблематичну архітектуру. Він використовується для взаємодії між AppDomain, яка більше не підтримується. Крім того, для віддаленого використання потрібна підтримка виконання, що досить дорого в обслуговуванні. З цих причин віддалене .NET не підтримується в .NET Core, і ми не плануємо додавати підтримку для нього в майбутньому.

Джерело: https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting

— Жан-Клод
джерело

1

Тут ви можете знайти обговорення того, які альтернативи доступні в .NET Core: github.com/dotnet/corefx/issues/18394

— Жан-Клод,

Згадується також тут: docs.microsoft.com/en-us/dotnet/core/porting/…

— Жан-Клод,

2

Клеменс Васстерс, технічний керівник службової шини Microsoft .NET (це означає як віддалення, так і WCF) розповідає про WCF проти віддалення в цьому дописі на форумі . Підсумовуючи допис, він в кінцевому підсумку рекомендує WCF замість Remoting.

Я не впевнений, чи використовує .NET 4.0 внутрішнє віддалення, але ви можете спробувати надіслати Клеменсу питання ... Я впевнений, що він знає відповідь.

— ЙоганнесH
джерело

11

Співробітник Microsoft рекомендує використовувати новий метод блискучого-нового-несумісного з усім-чим-небудь над будь-якою формою стандарту? Шокуючі.

— quillbreaker

14

Яким чином WCF не сумісний з усім іншим? А віддалення було сумісне з чим?

— Джон Сондерс,

2

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

— Марк

3

Я прийняв вашу пропозицію і запитав Клеменса. Його відповідь: "Віддалення є частиною .Net Framework, і, як таке, воно не зникає ... Для поточного, перехресного додаткового спілкування Віддалення - це рідний спосіб спілкування CLR".

— Марк

1

Далі він говорить, що вам слід "серйозно поглянути на WCF та NetNamedPipeBinding".

— Джон Сондерс,

2

Я думаю, що зараз (2015) це цілком зрозуміло навіть для доменів між додатками: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Видалення Cross AppDomains Ця тема стосується застарілої технології, яка зберігається для зворотної сумісності з існуючими програмами і не рекомендується для нової розробки. Тепер розподілені програми слід розробляти за допомогою Windows Communication Foundation (WCF).

Тоді WCF слід використовувати і для доменів між додатками.

— Армандо
джерело