Есть ли реальная потребность в серверной архитектуре для RIA-приложения?

Действительно ли нам нужна серверная архитектура для создания RIA-приложения?

Моя идея заключается в следующем:

  • Создайте полноценное приложение RIA, используя только HTML-страницы, JQuery и полный набор компонентов пользовательского интерфейса на стороне клиента (выберите свой яд из большого количества различных компонентов, доступных с открытым исходным кодом или нет)
  • На стороне сервера у меня есть только один или несколько REST, таких как веб-сервисы, которые возвращают и принимают сериализованные объекты Json.

Нет больше зависимости от последних тенденций в архитектуре на стороне сервера (Struts, Java Faces, Asp.Net, MVC или любая другая модель, которая была модной когда-то или модна сейчас), сторона веб-сервера будет просто интерфейсом между trasnsport (Json) и уровень бизнес-логики, в котором очень мало логики.

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

У вас есть комментарий к этому сценарию?

Чао Массимо


architecture ria
person massimogentilini    schedule 21.11.2008    source источник

Ответы (4)


arrow_upward
1
arrow_downward

С таким же успехом вы могли бы спросить о реализации первоклассного бэкенда, обеспечивающего правильную серверную часть, избегая при этом последних модных причуд клиентской стороны. И я думаю, что это было бы законной целью в любом случае. Вы не упоминаете, существует ли это приложение, но если это так, то я бы сказал, сначала запомните книгу Fowler Refactoring, а затем приступайте к ней.

Многие изменения в программном обеспечении полезны, если вы знаете, как правильно применять то, что вам нужно знать для достижения целей на стороне клиента, потому что одни и те же концепции (SOC, сцепление против сцепления, DRY, YAGNI и т. применимы к обоим концам, и у нас все чаще есть под рукой полезные инструменты для их применения (что может быть выполнено более или менее легко с помощью множества технологий).

person dkretz    schedule 21.11.2008
comment
Новое приложение, мы сейчас в середине дизайна, поэтому пришло время подумать, оставаться ли на том же старом пути или выбрать новый. - person massimogentilini; 21.11.2008
comment
Тогда я думаю, что то, что вы предлагаете, будет работать так же хорошо, как и любой другой дизайн проекта. В любом случае вы должны попытаться отделить архитектуры и сосредоточиться на хороших контрактах и ​​интерфейсах. - person dkretz; 21.11.2008
comment
Если вы это сделаете, то то, что вы знаете о рефакторинге, поможет вам в дальнейшем. - person dkretz; 21.11.2008

arrow_upward
1
arrow_downward

Просто не ставьте логику безопасности на стороне клиента... ;-)

person Chris Nava    schedule 01.01.2009
comment
И не ставьте проверку данных на стороне клиента! - person Guillaume; 13.01.2009

arrow_upward
0
arrow_downward

Или даже не беспокойтесь о части REST/Json и используйте что-то вроде DWR, чтобы напрямую общаться с кодом на стороне клиента с POJO вашего сервера.

person tinyd    schedule 21.11.2008

arrow_upward
0
arrow_downward

Большинству приложений RIA не требуется MVC или инфраструктура на основе компонентов, поскольку C, V и большая часть M находятся на клиенте. Однако вам все равно понадобится какой-то уровень служб, с которым клиент может общаться, и слой сохранения для работы с базой данных.

person cliff.meyers    schedule 01.01.2009