Распределенное приложение (WCF / Remoting / веб-серверы) и веб-приложение - PullRequest
1 голос
/ 24 декабря 2009

Я делаю стандартное приложение LOB среднего размера. В настоящее время это веб-приложение, но я формулирую предложение по преобразованию его в приложение для удаленного рабочего стола. Под этим я подразумеваю, что база данных и сервер приложений будут размещены в удаленном месте. Клиентское приложение будет связываться с сервером через Интернет (либо WCF / Webservices / Remoting).

У меня такой вопрос: единственная причина, по которой я перевожу это с веб-платформы, связана с веб-ограничениями (я не хочу делать сценарии AJAX или Java, чтобы минимизировать эти ограничения, поэтому, пожалуйста, никаких рекомендаций JS / AJAX) , Я сделал традиционные настольные приложения, и они довольно быстрые, но я никогда не делал удаленных или распределенных приложений. Я не уверен, будет ли скорость приложения быстрее, чем в Интернете, или нет.

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

Любая помощь в правильном направлении была бы отличной. Большое спасибо.

Zeeshan

Ответы [ 3 ]

1 голос
/ 24 декабря 2009

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

Лично мне не нравятся веб-приложения, которые требуют большого взаимодействия с пользователем, есть некоторые из них, которые приятно использовать, но я думаю, что очень легко сделать это неправильно и в конечном итоге иметь ошибку или приложение не так быстро реагирует (вероятно, из-за несовместимости браузеров, на моем компьютере установлены IE, Firefox и Chrome, и я использую один для некоторых веб-сайтов, потому что они работают на нем быстрее, а другие для других сайтов, потому что веб-страницы отображаются только правильно на них). Хотя это может и не быть проблемой для клиента Silverlight.

В случае скорости сети, в зависимости от того, что происходит в сети, даже с двоичной сериализацией, удаленное взаимодействие может привести к значительным накладным расходам. Например, наряду с данными он записывает полные имена классов, имена библиотек и их версии, поэтому он может быть довольно большим и медленным даже для небольших объемов данных (хотя он все равно должен быть меньше HTTP). У него также есть те же проблемы, что и у HTTP по ненадежным соединениям, потому что он использует аналогичный протокол. Для одного проекта нам пришлось написать собственный сериализатор для некоторых объектов, потому что одна двоичная сериализация генерировала 200 КБ, но наш собственный сериализатор для этих объектов генерировал 50 КБ. Затем мы закончили писать свой собственный сетевой протокол, потому что тот, который идет со временем выполнения, часто зависал в ненадежных беспроводных сетях, а удаленное взаимодействие не дает никакого контроля над созданным им сокетом (что имеет смысл с точки зрения инкапсуляции, но вы можете закройте его и заставьте открыть новый).

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

Переписать приложение только для максимальной скорости? Нет, потому что, вероятно, пользователь не увидит большой разницы во времени ответа.

1 голос
/ 24 декабря 2009

Вы несколько двусмысленны с вашей терминологией - хотите ли вы клиентское приложение, которое работает на компьютере пользователя, или вы хотите приложение, которое работает на сервере, и пользователь подключается через удаленный рабочий стол (RDP)?

Если вы говорите о клиентском приложении, которое взаимодействует с сервером через WCF и т. Д., То да, оно будет быстрее, чем стандартное веб-приложение, хотя все равно будет медленнее, чем собственное настольное приложение. Это будет быстрее, чем веб-приложение, не только из-за отсутствия обратных передач, но и потому, что вы будете отправлять чистые данные по проводам, а не огромное количество HTML / Javascript в сочетании с вашими данными. С клиентским приложением у вас есть несколько вариантов, поэтому тщательно обдумайте их - хотите ли вы Silverlight, WPF или собственное приложение WinForms? У каждого есть свои плюсы и минусы.

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

Редактировать

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

Что касается того, в чем вы пишете, вы не можете спорить с Winforms, если это то, где ваш опыт. Лично я бы никогда больше не использовал ASP.NET/Ajax/etc для приложений веб-типа, это были бы WPF или Silverlight полностью (я бы использовал ASP.NET только для простых веб-сайтов). Вы можете использовать экспресс (бесплатные) версии Visual Studio для написания этого, вам не нужно Expression (это просто приятно иметь, и больше нацелено на сторону дизайна, чем на фактическую сторону кодирования). Развертывание приложения не должно быть сложным - Silverlight или WPF xbap доставляются через Интернет, пользователь ничего не должен делать (кроме простой установки плагина Silverlight или установки правильной .Net Framework для WPF - проверьте эту ссылку ). Winforms или автономный WPF требуют немного больше работы, но вы можете избежать большинства проблем, написав хороший установщик.

Какой бы вариант вы ни выбрали, убедитесь, что вы не недооцениваете время для разработки (потому что у вас будет некоторая кривая обучения), а также убедитесь, что у вас достаточно времени для его тестирования, особенно с точки зрения безопасности. :)

0 голосов
/ 24 декабря 2009

Я был в похожей ситуации, хотя и начал с приложения Winforms LOB.

Вот что мы нашли с WinForms ...

  • В вашем цикле выпуска будет сложнее развернуть все клиентские машины.
  • WinForms не могут быть легко запущены в других операционных системах. (за исключением моно)
  • Конечные точки WCF могут быть сложными, и вам необходимо управлять конечной точкой для выпуска / версии вашего приложения.
  • Аутентификация, авторизация и безопасность могут быть сложными, чтобы получить право!

Вот почему вы должны придерживаться HTML-веб-приложения.

  • его будет проще развернуть, так как вам просто нужно скопировать один набор DLL в папку bin. Может создаваться с помощью сервера непрерывной интеграции или промежуточной обработки.
  • Безопасность станет проще благодаря использованию SSL-сертификата.
  • Silverlight / Flash должен заполнить пробелы, которые пропускает HTML.

Microsoft также объединила подключенные системы в .net 3.5, теперь они называют это WCF (ASMX / Remoting / etc ...). У него достаточно времени на обучение 4-5 недель.

...