Когда выбирать между веб-интерфейсом и родным графическим интерфейсом? - PullRequest
12 голосов
/ 15 марта 2009

Многие приложения (особенно сетевые, например, для обмена файлами, программы запросов SQL, некоторые многопользовательские игры), как мы знаем сегодня, могут быть легко предоставлены с помощью веб-интерфейса.

У меня вопрос, когда я должен сделать приложение доступным с помощью браузера?

Когда будет разумно использовать настольное приложение, построенное с использованием таких интерфейсов, как Qt, Visual Basic и т. Д.

Ответы [ 8 ]

3 голосов
/ 15 марта 2009

Некоторые баллы за веб-интерфейс:

  • Когда программа должна быть администрируется с другого компьютера на сеть
  • При более быстром развитии нужна скорость (обычно быстрее писать html / javascript, чем Qt / Gtk и т. д.)
  • Чтобы программа оставалась перекрестной Платформа совместима насколько это возможно
2 голосов
/ 15 марта 2009

На этот вопрос нет общего ответа. Это зависит от некоторых факторов:

  • Ваша целевая группа - Широко распространено или объединено?
  • Портативность - На каких платформах работают ваши пользователи?
  • Производительность - Многое ли нужно? Если да, настольное приложение будет лучше. Я не могу представить программное обеспечение для редактирования видео, запущенное в браузере. Может быть через 10 лет:)
  • и более, которые должны быть определены индивидуально

Но эта тенденция явно распространяется на веб-приложения. С ними можно связаться довольно много людей.

1 голос
/ 17 сентября 2016

Для разработки приложения лучше всего разделить код клиента и сервера. В настольном приложении это обычно не так. Код клиента, который обрабатывает взаимодействие с пользователем, интегрирован с кодом сервера, который обрабатывает пользовательские команды. Однако в этом нет необходимости просто разделять код и обмениваться данными по TCP / IP.

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

Большинство каркасов GUI являются мультиплатформенными.

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

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

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

1 голос
/ 15 марта 2009

По своему опыту я обнаружил, что разработка веб-приложений обычно занимает немного больше времени, но есть некоторые преимущества в разработке веб-приложения.

  1. Вам не нужно развертывать веб-приложения
  2. Люди часто более привыкли использовать веб-браузер, чем пользовательское приложение, поэтому, как правило, приложение получает удобство использования
  3. Обычно пользователям проще найти то, что они ищут в веб-приложении, благодаря интерфейсу.
  4. Вам нужно тестировать только с несколькими браузерами, и вам не нужно тестировать множество конфигураций клиентов, которые могут конфликтовать.
  5. С веб-приложением вам не нужно заботиться о том, какую операционную систему может использовать клиент. Например, предположим, что ваша компания решает перевести свои настольные компьютеры в Linux, вам не придется создавать новую версию.

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

1 голос
/ 15 марта 2009

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

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

1 голос
/ 15 марта 2009

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

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

Компания разработала клиентское приложение .net, и они получили грубое пробуждение. Компания не была готова к сложности развертывания на любом количестве клиентских конфигураций. Например, мы получили немного от Novell Networks. Они не были готовы к увеличению стоимости поддержки клиентского приложения. (И да, разработчики предупреждали и пытались предупредить их, что это значит).

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

Что нужно спросить:

  1. Прежде всего, может ли ваше приложение работать как веб-приложение? Некоторые приложения просто не осуществимы. если вам нужен доступ к низкоуровневым ресурсам, у вас не будет много вариантов.
  2. Можете ли вы позволить себе расходы на обслуживание клиентского программного обеспечения? Если это распределенное приложение, что происходит, когда вы обновляете сервер, но клиенты не обновляются.
  3. Можете ли вы поддержать клиента?
  4. Какой опыт создает команда по созданию программного обеспечения? Это огромное ИМХО. Независимо от того, насколько хороши команды в создании веб-приложений, они будут совершать ошибки при работе с клиентскими приложениями, а опытный клиентский разработчик - нет.
1 голос
/ 15 марта 2009

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

Если вы начнете с веб-интерфейса, вам никогда не понадобится отдельный проект для создания веб-интерфейса.

С современными браузерами, библиотеками javascript и ajax и javascript вы можете создать чрезвычайно богатый интерфейс, который можно легко изменить.

0 голосов
/ 15 марта 2009

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

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

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