Подтвердить что ты не робот

Почему веб-приложения распространены для внутренних корпоративных приложений?

ОК, я понимаю, что людям не нравится устанавливать вещи на своих ПК, если им это не нужно, и это основное преимущество веб-приложений поверх "рабочего стола", которые выполняются локально.

Но для корпоративных внутренних приложений, где безопасность не является проблемой, если приложение таково, что его пользовательская база имеет приложение в 100% случаев, используя его исключительно в качестве основного инструмента, не было бы настольным приложением лучший выбор?

У меня нет опыта/много знаю о веб-приложениях WPF, но я считаю, что это приложение, которое работает локально на вашем ПК с ОС Windows. Я больше знаком с тем, что, вероятно, является более старой технологией, WinForms, в частности, развертыванием приложения WinForm с помощью технологии ClickOnce.

Мне кажется, что Click-Once (и, предположительно, WPF Web Apps), для практических целей, решили проблемы с развертыванием dll hell в прошлом, но мне кажется, что обращение к использованию веб-приложений было внутренним образом, чтобы избежать адский аддон, связанный с локальными установками. Тем не менее, когда эта проблема решена, почему компании все еще избегают/боятся приложений, которые связаны с локальной установкой и настолько быстро тянутся к веб-приложениям?

Мне кажется, что преимущества настольных приложений

1) COST - Настольные приложения просто концептуально проще, потому что у вас есть все ресурсы локального компьютера, и у вас есть состояние. В результате настольные приложения GOT TO BE намного дешевле разрабатывать для той же функциональности. Посмотрите на весь сложный азартный код Ajax на стороне клиента/сервера, который нужно пройти, чтобы делать вещи, которые были бы тривиальны в настольном приложении. Я представляю людей, оспаривающих этот момент, но для меня это очевидно и выходит за рамки дискуссий.

2) Настольные приложения, как правило, богаче. Веб-приложения в лучшем случае сопоставимы за счет более сложных/дорогих разработок кода. (до 1)

Я могу перечислить больше, но их должно быть достаточно...

Очевидно, что настольные приложения не подходят для всех внутренних веб-сайтов. Но возьмите это в качестве примера и скажите мне, если вы считаете, что веб-приложение для настольных приложений является лучшим выбором:

Приложение справочной службы ежедневно использует 8 часов/день для пользователей и является единственным приложением на своих ПК. Кроме того, приложение исправлено редко.

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

Изменить # 1: Вот пример приложения Click Once Desktop (интегрированный интерфейс для Rational Clearquest/Sharepoint/PVCS/Mercury для управление пробными билетами), которые используют компьютерную мощь клиента для локального хранения информации и позволяют пользователю нарезать и копировать данные по-разному, не ударяя по серверу каждый раз, в то же время позволяя пользователю связывать реальное время с живым данные для обновления отдельных записей. Это похоже на загрузку электронных таблиц, которая поддерживает ссылки на данные сервера, если пользователь хочет выполнить обновление.

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

4b9b3361

Ответ 1

Почему веб-приложения распространены для внутренних корпоративных приложений?

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

Теперь я не уверен, что настольное приложение обычно дешевле (я не знаю, дешевле ли разработка, но я уверен, что обслуживание, поддержка... не являются).

Однако я согласен с тем, что настольные приложения, как правило, богаче. Независимо от того, что люди будут требовать, этот не был аргументом до появления AJAX и это все еще применяется в некоторых конкретных областях, где браузер просто не подходит, с AJAX или без него ( попросите трейдера использовать браузер, и вы увидите). Некоторые люди не не нуждаются в парадигме потока страниц, некоторые люди делают нуждаются в дополнительных виджетах (например, компонент сетки с расширенной фильтрацией, группировкой, функциями Excel, такими как базовые формулы и т.д.), или с низкой задержкой, или в режиме реального времени и т.д., то есть вещи, которые Rich Internet Application - или RIA - на самом деле не созданы и, следовательно, не являются подходящим инструментом для выбора!

И я тоже согласен с тем, что такие технологии, как Java WebStart или Microsoft ClickOnce, решают проблему старого развертывания и позволяют создавать так называемые Rich Desktop Applications - или RDA - (богатый пользовательский интерфейс рабочего стола на клиенте, бизнес на сервере, стандартный протокол между ними и централизованным развертыванием, так что все еще тонкий клиент), который, кажется, отличный компромисс (лучший пользовательский опыт, но без головной боли).

Итак, почему люди систематически опускают опцию RDA? Ну, я считаю, что:

  • Мы (специалисты в области ИТ) научили людей создавать интернет-приложения, чтобы они просто (повторно) это делали.
  • Он уже достаточно сложный, чтобы объяснить Интернет, тонкий клиент, AJAX, RIA и т.д., и на RDA не так много евангелизации. Поэтому большинство людей просто не знают, что такое RDA.
  • Мы (ИТ-специалисты) постоянно говорим что-то и наоборот: не используйте толстый клиент, он сосет, пользуется тонким клиентом, он управляет, не использует javascript, он отстой (до AJAX эры), используйте javascript, это правило (пост AJAX эпохи), не используйте тонкий клиент (!), он сосет, использует богатое настольное приложение, его правила и так далее. Даже если в этом есть логика, это приводит к тому, что некоторые понятия (например, RDA) трудно продать нетехникам в конце.
  • Люди не забывают о плохом опыте, который легко (толстый клиент), даже если с тех пор ситуация изменилась.
  • На самом деле людям действительно не нужно RDA, пусть говорят 95% ситуаций.
  • Разработчиков RIA больше, чем разработчиков RDA.

Так что это наш (мы, ИТ-специалисты):)

Ответ 2

Веб-приложения превалируют по многим причинам:

  • Его легко защитить
  • Он создает стандартную точку отсчета, к которой каждый может получить доступ:
  • Не блокирует людей, использующих разные платформы.
  • Легче для людей доступ извне сети (он ставит проблемы безопасности на маршрутизаторы /vpn и т.д.)
  • Менее техническая поддержка (стандартная рабочая платформа)
  • Легче поддерживать (если он идет вниз, тогда у вас есть команда критического реагирования, которая может исправить это, а не 1000 машин, которые случайно упадут).
  • Центральная точка хранения данных (проще для резервного копирования и доступа)
  • Может масштабироваться лучше
  • Легче создавать или повторно использовать инфраструктуру предприятия, чем находить/создавать распределенный компонент, работающий с изменяющейся средой (LDAP, разные dbs, разные резервные копии, синхронизация).
  • Меньше подвержены атакующим (черви, люди, изменяющие клиента и т.д.)
  • Настольные клиенты иногда могут иметь жестко закодированные среды или требуют определенных наборов инструментов, которые заставляют новых пользователей болеть за настройку
  • Его дешевле иметь дело с сервером, а не с тысячами клиентов. Вы можете настроить системы, которые будут восстановителями, и иметь быстрый отказ. Да, серверное оборудование стоит в несколько раз, но в долгосрочной перспективе оно стоит меньше.

Ответ 3

Я согласен с тем, что веб-приложения не развиваются быстрее - если у вас не более одной ОС для поддержки или подключения к базе данных, которое применяется в основном ко всему, что я делаю.

  • 20% моих пользователей не работают Окна.
  • 100% моих пользователей хотят используйте приложения внутренней сети из дома.
  • 100% моих пользователей хотят видеть их личные данные независимо от того, где они подключаются.
  • Никто не любит рассказывать "пожалуйста, подождите, пока мы обновим вас до версии 3.0.1"

Программы создания документов (в том числе графические программы) явно более подходят для рабочего стола, несмотря на то, что Google Docs вы бы подумали. Вы не хотите, чтобы звуковой или видеоредактор работал удаленно. Но чем менее личная работа - чем более совместная (корпоративная), тем больше имеет смысл webapps.

Ответ 4

  • Более быстрое время разработки
  • Простота развертывания (вы, вероятно, будете развертывать несколько раз)
  • Некоторые корпоративные ИТ-группы не позволяют пользователям устанавливать приложения.

**** **** Edit

  • Легче гарантировать производительность сети приложений к базе данных
  • База данных более безопасна
  • Легче объяснить, как запустить приложение.
  • Не нужно хранить или устанавливать дополнительные библиотеки (обычно)
  • Легче поддерживать (как разработчиками, так и ИТ)

Ответ 5

  • Веб-приложения намного проще обновлять. Внутренняя команда разработчиков может обновлять сайт, даже если пользователи не замечают.
  • Веб-приложения обычно используют меньшую пропускную способность, чем жирные клиенты. Если у вас есть несколько офисов или продавцов на дороге, пропускная способность важна. Попробуйте использовать (в худшем случае, я могу придумать) MS Access для подключения к удаленной базе данных по линии 1mb - она ​​не работает.

Ответ 6

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

После этого я создал webapp для той же компании. Он также использовался тысячами людей. После того, как мы закончили разработку и тестирование приложения, весь процесс распространения состоял из 1) развертывания в prod и 2) отправки URL-адреса всем. Намного проще предоставить каждому доступ к веб-приложению и небольшую часть проблем с поддержкой.

Ответ 7

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

Ответ 8

Он также позволяет упростить масштабируемость и надежность приложения. Поместив его на резервный сервер (возможно, в кластере), вы разрешаете использовать один источник для развертывания (@Gabriel), и вам остается меньше беспокоиться о способе обслуживания системы. Вам не нужно беспокоиться о том, что Мэри PC в зале слишком медленно, чтобы запустить приложение. Это также снижает требования к доступу/безопасности к источникам данных. Благодаря новой разработке веб-сайта MVC, n-level и т.д. Доступ к данным распределяется на особый слой, а не на то, чтобы каждый tom/dick/harry имел доступ к нему.

Ответ 9

Давайте рассмотрим ваш ответ 1) COST - Настольные приложения просто концептуально проще, потому что у вас есть все ресурсы локального компьютера, и у вас есть состояние. В результате настольные приложения GOT TO BE намного дешевле разрабатывать для той же функциональности. Посмотрите на весь сложный азартный код Ajax на стороне клиента/сервера, который нужно пройти, чтобы делать вещи, которые были бы тривиальны в настольном приложении. Я представляю людей, оспаривающих этот момент, но для меня это очевидно и выходит за рамки дискуссий.

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

С веб-приложениями приложение является браузером. Каждая машина легко конфигурируется с браузером, который поддерживается с более низкой стоимостью.

2) Настольные приложения, как правило, богаче. Веб-приложения в лучшем случае сопоставимы за счет более сложных/дорогих разработок кода. (до 1)

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

Ответ 10

  • Поскольку веб - универсальная платформа, а клиентские ОС - нет.
  • Поскольку разработка и поддержка кода на стороне сервера проще, чем разработка и поддержка кода на стороне сервера и на стороне клиента.
  • Поскольку сеть стабильна и основана на стандартах, в то время как клиентские ОС являются собственностью и развиваются.
  • Потому что сеть переведет ваши текущие ИТ-политики и корпоративную структуру. (Когда вы сливаетесь с компанией B, и у 5000 пользователей появляются их устройства Chromebook, ваши смарт-приложения для Windows не выглядят такими умными).
  • Потому что 99% процентов корпоративных приложений - CRUD-приложения. Если вам нужна обработка данных на стороне клиента, тогда дамп в Excel.
  • Потому что удачи в поиске разработчиков Windows-клиентов. Деньги, действия и таланты - это все в Интернете и мобильных устройствах.

Ответ 11

Независимость платформы/браузера очень неверна для ответа на вопрос.

В многочисленных ответах не упоминалось, что многие организации будут создавать и использовать веб-приложения, предназначенные для определенной версии определенного браузера. Легче разработать что-то, что работает и выглядит правильно только в 1 веб-браузере. Пример: IE5, IE7 и т.д.

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

По этой причине разработчики будут писать и тестировать свои веб-приложения только на определенном браузере/платформе.

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