Каковы преимущества миграции нашего приложения на WCF по сравнению с продолжением использования .NET Remoting?

Есть множество причин отказаться от удаленного взаимодействия; некоторые из них могут включать:

• отсутствие транспортной гибкости
• требования к версиям - огромная боль
• зависит от платформы (нет заметных шансов на кроссплатформенное использование)
• нет шансов на использование на растущем мобильном рынке
• отсутствие будущего развития: какую бы функцию вы ни добавили - ее не будет

однако я бы не согласился с тем, что WCF является автоматической заменой; WCF сам по себе является довольно универсальным инструментом, но может быть довольно сложным и иметь собственные ограничения. Я сам не использовал его, но видел множество похвал за Сервисный стек, по сути, пользователи описывают это как «WCF сделано правильно», то есть хорошие части WCF, без проблем. Однако есть и другие варианты. Тем не менее, одна хорошая вещь в идее Service Stack заключается в том, что он выполняет итерацию довольно быстро, и если в нем чего-то не хватает, вы можете это изменить.

.NET Remoting теперь является устаревшей технологией, цитируемой из MSDN:

Этот раздел относится к устаревшей технологии, которая сохраняется для обратной совместимости с существующими приложениями и не рекомендуется для новой разработки. Распределенные приложения теперь следует разрабатывать с использованием Windows Communication Foundation (WCF).

А вот сравнение производительности WCF и .NET Remoting, проведенное в 2007 году: http://msdn.microsoft.com/en-us/library/bb310550.aspx

Подводя итог, можно сказать, что WCF на 25–50% быстрее, чем веб-службы ASP.NET, и примерно на 25% быстрее, чем .NET Remoting. .

Поэтому я думаю, что скорость - хорошая причина отказаться от .NET Remoting.

Хотя приведенные причины, вероятно, являются соображениями вождения, есть и другие нетривиальные причины:

• Транспортная независимость
• Инструменты IDE
• Легкость тестирования
• Ремонтопригодность

Когда вы используете WCF, вы можете изменить транспорт, просто отредактировав файл конфигурации. Это может быть очень удобно, когда какой-то ханжеский системный администратор не открывает порт, и вам нужно использовать HTTP на порту 80, чтобы пройти через корпоративный брандмауэр.

Инструменты WCF в Visual Studio феноменальны. Самое сложное - выяснить, какой URL вам нужен. После этого просто наведите указатель мыши и щелкните для генерации кода. Есть одна или две ошибки с сериализацией коллекций, но в целом, если вы скажете обоим сторонам использовать массивы, это будет просто работать. Если вам нужна коллекция в месте назначения, вы всегда можете построить ее вокруг полученного массива, и, поскольку LINQ будет успешно работать с массивами, вы можете добавить ее в другие преобразования.

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

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

WCF значительно упрощает мой код, поскольку ни приложение, ни служба не загрязнены кодом «маршрутизации» (чтобы определить, что должно обрабатывать содержимое сообщения); это похоже на вызовы или реализации простых методов. Я в основном использую WCF в качестве оболочки для MSMQ, и единственное видимое следствие выбора транспорта состоит в том, что все эти вызовы методов должны быть недействительными функциями, потому что это транспорт OneWay. Но это неудивительно, если речь идет о постоянной очереди.

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

Кроме того, существует возможность взаимодействия с несовместимыми платформами. В этом случае я думаю об использовании HTTP / XML или HTTP / JSON для обслуживания веб-приложений, написанных (например) на PHP.

Идти другим путем не так-то просто, но довольно просто.

Я даю очки WCF за ведение журнала и безопасность.

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

Безопасность. Механизм безопасности в WCF довольно прост и нестандартен, если смотреть с точки зрения разработчиков, но он очень надежен и очень безопасен. Самое приятное то, что для часто используемых и рекомендуемых привязок WCF обеспечивает безопасность по умолчанию, которую можно доверять ядру. Безопасность сообщений на WSHTTPbinding является примером в этих строках.

Удаленное взаимодействие .NET Framework по умолчанию не выполняет проверку подлинности или шифрование. Поэтому рекомендуется предпринять все необходимые шаги, чтобы удостовериться в идентичности клиентов или серверов, прежде чем взаимодействовать с ними удаленно.

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