соображения по выбору подхода веб-приложения? - PullRequest
Новая
       42

соображения по выбору подхода веб-приложения?

2 голосов
/ 20 декабря 2009

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

Первый подход заключается в использовании технологий, которые идут от клиента к серверу и обратно, таких как Struts, SpringMVC, JSF и так далее.

Второе - использовать технологии, которые в основном работают на клиенте, такие как Flex, Swing (веб-запуск), JavaFX и т. Д.

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

Мне бы очень хотелось узнать, когда вы предпочитаете использовать каждый из них? Что следует учитывать при выборе одного над другим?

Скажите все, что придет вам в голову, с точки зрения безопасности, типа приложения, Stateless / Statefull, вызовов DB или чего-либо еще.

Было бы интересно узнать, каковы различные аспекты.

Ответы [ 2 ]

4 голосов
/ 20 декабря 2009

В основном, различие между «худыми» и «толстыми» клиентами.

Некоторые плюсы и минусы обоих

Толстый клиент

  • Возможность передавать больше логики обработки клиенту, уменьшая ресурсы сервера. Это также может привести к улучшению взаимодействия с пользователем, поскольку графический интерфейс пользователя может одновременно выполнять задачи обновления.
  • Клиенту проще работать в автономном режиме
  • Может быть проще реализовать более сложные и сложные функции графического интерфейса
  • НО может быть сложнее повторно использовать логику для разных типов клиентов (например, для настольных и мобильных устройств)
  • НО может быть сложнее в кодировании, требует больше специальных навыков, чем общий веб-клиент-серверный подход, и иногда означает, что большая часть логики приложения закодирована в клиенте, что приводит к меньшему разделению интересов.
  • НО часто проприетарный (например, гибкий)
  • НО может быть сложнее предоставлять данные сканерам

Тонкий клиент

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

Появление более мощных браузеров, таких как Chrome, стирает границу между ними.

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

1 голос
/ 25 июня 2010

Мой совет - избегать плагинов во всех случаях. Не используйте плагины java, flash или silverlight для веб-приложений. Вы настраиваете себя на мир боли в будущем. Если вы хотите создать богатый клиент, используйте что-то, что генерирует JavaScript. Если вам нравится Java, используйте GWT. Если Java не ваша чашка чая, посмотрите на наборы инструментов javascript, такие как ExtJS, Dojo, Sproutcore.

То, как я вижу компромиссы:

Тонкий клиент (обычный HTML):

  • Перевернутый: легче адаптируется к различным браузерам и устройствам
  • Upside: лучше для устройств с низкой пропускной способностью
  • Недостаток: меньше возможностей в элементах управления пользовательского интерфейса
  • Недостаток: время туда-обратно убьет «поток». Если ожидается, что пользователи будут долго работать в вашем приложении, этот подход не будет работать хорошо.

Богатый клиент (инструментарий GWT или JS):

  • Перевернутый: серверная часть может реализовывать только чистый API
  • Перевернутый: дизайн пользовательского интерфейса проще, богаче
  • Upside: вы можете планировать свой дизайн на медленное время туда и обратно (с «автономным режимом», который является крайним случаем медленного времени туда и обратно)
  • Недостатки: нужен отдельный интерфейс для мобильных устройств и браузеров с низким энергопотреблением
  • Недостаток: низкая пропускная способность сделает загрузку настолько медленной, что пользователи просто уйдут

Для моих приложений я попадаю прямо в лагерь богатых клиентов. Но тогда я не делаю приложения для «публичного» интернета.

...