Веб-приложение, использующее jQuery standalonne и среду представления на стороне сервера

Question

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

1. Автономный клиент на основе JavaScript, использующий такую ​​инфраструктуру, как jQuery UI
2. Гибридный клиент, использующий клиентскую среду, такую ​​как jQuery UI, плюсинфраструктура на стороне сервера, такая как ASP.NET MVC3, JSF, GWT и т. д.

Каково ваше мнение о плюсах и минусах каждого подхода?В первую очередь я ищу возможность применять хорошие архитектурные принципы (такие как MVC и Eventing) для создания чистого модульного дизайна, который легко понять и поддерживать.

Редактировать: Взгляд наВ ответах я хотел бы уточнить, что существует серверный компонент, который выполняет основную часть бизнес-логики (см. эту диаграмму архитектуры ).Клиент просто отправляет свои команды и запросы на сервер, используя службы на основе JSON.В этом отношении клиент действительно легкий и сосредоточен только на взаимодействии с пользователем и его представлении.

Итак, что я на самом деле ищу, так это:

a) руководство о том, какие структуры использовать для подходов1 и 2 для достижения чистых модульных конструкций

б) Мнения о том, почему один подход будет работать лучше, чем другой

Например, я бы склонялся к # 1 при условии, что комбинация фреймворков JavaScript будетДостаточно легко создать надежный уровень представления.Другими словами, если я собираюсь инвестировать в тяжелый клиент JavaScript, зачем вводить дополнительные зависимости в инфраструктуру на стороне сервера - действительно ли это облегчает мою работу?(при условии, что в любом случае задействована кривая обучения)

Answer 1

GWT на стороне клиента.Он может заменить jQuery, если вы используете его с gwtQuery.

Выбор технологии действительно зависит от многих факторов (о которых вы здесь не упоминали), но в основном от того, что вы уже знаете.Лично я бы пошел с:

1. GWT и gwtQuery на стороне клиента, в основном потому, что я их знаю.Клиентом будет pure-ajax, где вся бизнес-логика выполняется на сервере.

2. REST-сервер, выполняющий бизнес-логику и обслуживающий (представление) данных клиенту.Есть много технологий REST, лично я знаю Resteasy, поэтому я бы использовал это.

Обновление:

Вкл. 1. против 2.подход: подход 1. в основном используется в сложных веб-приложениях (также называемых gmail), где веб-страница не перезагружается и все взаимодействие осуществляется с помощью манипуляций с DOM и вызовов AJAX.Это дает вам лучшую отзывчивость (страница не перезагружается) и лучшее время загрузки (так как почти не передается HTML, только данные JSON).Если вы хотите иметь богатый опыт работы с пользовательским интерфейсом, вам все равно нужно будет использовать JS на стороне клиента, поэтому вы никогда не будете полностью избегать этой части.

Недостатком является то, что вам нужно знать JS.Кроме того, код JS имеет тенденцию иметь проблемы с удобством сопровождения при расширении базы кода.ОДНАКО, все это может быть смягчено, если вы используете GWT: java имеет статическую типизацию, компилируется в JS минимального размера и абстрагируется от браузера (обеспечивает абстрагированный доступ к DOM).Также он имеет отличную поддержку IDE (Eclipse и IDEA), GUI Builder (если вы этого хотите), модульность ( MVP ), отличные документы, множество библиотек и, мой любимый, gwtQuery (клон jQuery).

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

Answer 2

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

По теме обслуживания: JS, выполняемый на стороне клиента, вероятно, никогда не будет так легко обслуживать, как приложение MVC. Это просто вопрос личной или командной дисциплины, чтобы код был хорошо читаемым и обслуживаемым.

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

Обновление связано с обновленным вопросом:

В случае уже обработанной логики, когда клиенту только нужно выполнять обновления и манипулирование DOM, я бы, вероятно, решил на основе серверной архитектуры или личных предпочтений. Это зависит от долгосрочной цели. Если вы хотите придерживаться одной архитектуры, вы можете, например, использовать ASP.NET, которая предлагает различные элементы управления / объекты с поддержкой AJAX.

Лично я бы использовал AJAX-функции jQuery просто потому, что знаю, что до сих пор он безупречно работал с JSON Objects (в нашей интрасети мы используем его с бэкэндом Asp.NET), а jQuery довольно легок клиент. Миниатюрная версия не так много весит в байтах и ​​уже оптимизирована для производительности и несовместимости между браузерами. С помощью asp вам все равно придется самостоятельно искать кросс-браузерные прерыватели сделок, вместо того чтобы сосредоточиться на поставленной задаче, сам клиент