Мнения / заголовки для разделения приложения на front-end / back-end (не user / admin, а ui / logic) - PullRequest
1 голос
/ 22 января 2011

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

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

  • Back-End: Java + JAX-WS
  • Внешний интерфейс: Кохана 3.1 (PHP)
  • Формат обмена данными: JSON

Преимущества

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

Недостатки

  • латентность (??)
  • больше серверов

Так что ты думаешь? Это хорошая идея? Пока мне не удалось найти много информации, но я думаю, что многие крупные сайты делают это так, верно? Как повлияет производительность (я думаю запустить ее на EC2)? Каковы дополнительные преимущества / недостатки? Есть мысли о выборе языков / рамок?

Ответы [ 2 ]

1 голос
/ 22 января 2011

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

И если вы уже настроили JSON, вы можете изучить идею НЕ отображать POJOS на ваши данные и использовать хранилище документов, такое как MongoDB или CouchDB, для прямого доступа к данным JSON.

1 голос
/ 22 января 2011

Часто используется подобный архитектурный шаблон, хотя обычно часть пользовательского интерфейса часто перемещается к клиенту.Таким образом, у вас есть серверная часть, которая отвечает JSON, быстрый http-сервер с полнофункциональным кэшированием (который также может использовать кэширование приложений html5) и богатый клиент JavaScript, который запрашивает JSON из серверной части и создает пользовательский интерфейс.

Подробнее об этом шаблоне: http://www.metaskills.net/2008/05/24/the-ajax-head-design-pattern/

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

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