Позвольте мне начать с рассказа о моем друге, техническом руководителе в компании малого бизнеса. На него была возложена задача по обогащению приложения «Расходы компании» с помощью технологий Ajax. Сначала он планировал доставить заявку через 3 месяца, но в итоге он занял 6 месяцев. Вот некоторые «смертельные грехи Аякса», которые задержали его проект:
- Несовместимость браузера
Во-первых, он решил разработать собственный код JavaScript для пользовательского интерфейса, первый проект которого занял у его команды 2 месяца. Затем он обнаружил, что макет был беспорядок в разных браузерах. Из-за недостатка знаний JavaScript он решил принять готовую инфраструктуру виджетов Ajax вместе с рамкой Java-to-JavaScript, чтобы преодолеть эту проблему несовместимости браузера; это, конечно, означало восстановление пользовательского интерфейса с нуля. - Утомительное кодирование связи между клиентом и сервером
Как только выяснилось, что его команда избежала кошмара JavaScript, возникла еще более сложная задача, связанная с интеграцией между пользовательским интерфейсом и серверной частью: инфраструктура Java-JavaScript требовала вызовов RPC для получения данных. с сервера и обработать возвращенные данные вручную. Он создал множество файлов для связи между клиентом и сервером. Несмотря на развитие на чистой Java, его команда провела еще несколько месяцев, заканчивая интеграцию. - Низкая производительность
Во время тестирования их пользователями было обнаружено, что производительность неприемлема; пользователи должны были ждать более 10 секунд для загрузки 10 тысяч записей. Еще хуже, некоторые старые компьютеры фактически остановились. К сожалению, им пришлось реализовать нагрузку по требованию, чтобы улучшить проблему производительности. Но загрузка по требованию никогда не была легкой работой. Это потребовало определения видимой области на стороне клиента, запроса необходимых данных со стороны сервера и рендеринга данных в браузерах. Чтобы выполнить это требование, его команде пришлось отложить проект на несколько дополнительных месяцев. - Головная боль при обслуживании
Позже в цикле проекта ему сообщили, что в модель данных будут добавлены дополнительные поля. Это было настоящим кошмаром для его команды, поскольку они должны были не только изменить внутренний код, но и связанный с ним код клиента. Они потратили еще один месяц на поддержание согласованности бизнес-логики между кодом клиента и сервера. В конце концов, его команда потратила 6 месяцев, чтобы доставить заявку на «Расходы».
Trouble Maker: примитивная модель программирования
С моей точки зрения, большинство из этих проблем вызваны примитивной моделью программирования, которая разделяет пользовательский интерфейс и серверную часть приложения на две стороны следующим образом:
двусторонняя модель программирования создает много проблем для разработчиков, поскольку им приходится сами позаботятся о следующих проблемах, не связанных с процессом:
- Несовместимость браузера
больше не проблема, решаемая любыми современными фреймворками Ajax - Связь клиент-сервер
Отображение данных на клиенте путем извлечения данных с сервера - Низкая производительность
Разработчики склонны размещать слишком много данных на клиенте - Несоответствие бизнес-логики между клиентом и сервером.
Репликация бизнес-логики на клиенте.
Идеальная модель программирования должна избавить разработчиков от этих громоздких задач. Для одновременного решения всех вышеуказанных проблем пользовательский интерфейс и серверная часть приложения никогда не должны разделяться. Вместо этого они должны работать на одной стороне, либо на стороне сервера, либо на стороне клиента.
Чтобы повысить производительность труда разработчиков и обеспечить более легкий доступ к ресурсам сервера, приложение должно запускаться только на сервере. Идеальная модель программирования должна выглядеть следующим образом:
разработчики должны просто сосредоточиться на бизнес-логике своего приложения, а остальная часть работы должна автоматически выполняться принятой средой. Насколько мне известно, лучший способ использовать Ajax — это даже не знать, что он существует!
Я буду называть эту среду Direct Ajax, поскольку приложение может напрямую обращаться к пользовательским интерфейсам, базе данных и всем видам ресурсов. Direct Ajax предоставляет разработчикам более простой способ создания многофункциональных интернет-приложений, не беспокоясь о задачах, не связанных с процессами.
Прямой Аякс
Архитектура Direct Ajax выглядит следующим образом:
пользовательский интерфейс и серверная часть приложения полностью интегрированы, а Direct Ajax отвечает за визуализацию контента клиенту и автоматическую синхронизацию состояния между клиентом и сервером.
Прямое программирование
Прямое программирование должно соответствовать следующим трем критериям:
- Прямой доступ к пользовательскому интерфейсу
Приложение может напрямую получать и устанавливать значения из пользовательского интерфейса. Вот псевдокод,<zscript>
void draw(int x1, int y1, int x2, int y2) {
LiveImage li = new LiveImage(400, 300, LiveImage.TYPE_INT_RGB);
Graphics2D g2d = li.createGraphics();
Line2D line = new Line2D.Double(x1, y1, x2, y2);
g2d.draw(line);
image.setContent(Images.encode("test.png", li));
}
</zscript>
<image id="image">
<button onClick='draw(10,10,10,10)'/>Когда пользователь нажимает кнопку, в браузере появляется изображение. Это просто. Больше нет XMLHttpRequest и RPC-вызова. Больше не будет кувшина и ловца между клиентом и сервером.
- Прямой
доступ к базе данных Во-вторых, приложение может напрямую обращаться к базе данных. В следующем примере показан простой сценарий получения данных из базы данных.Hi. <label id="name"/>
<button>
<attribute name="onClick">
User usr = Database.getUserById(1);
name.setValue(usr.getName());
</attribute>
</button>Как только пользователь нажимает кнопку, появляется приветственное сообщение. Пользовательский интерфейс и серверная часть интегрированы без проблем.
- Прямые данные в реальном времени
С живыми данными разработчики могут отделить данные от представления. Разработчики предоставляют данные только путем реализации интерфейса ListModel вместо непосредственного управления сеткой.
<zscript>
String[] data = new String[1000];
for(int j=0; j < data.length; ++j) {
data[j] = "option "+j;
}
ListModel strset = new SimpleListModel(data);
</zscript>
<grid width="100px" height="100px" model="${strset}">
<columns>
<column label="options"/>
</columns>
</grid>
Сетка отправляет данные клиенту, только если они видны. Это экономит много сетевого трафика, если объем данных огромен.
Direct Ajax с прямым доступом к пользовательскому интерфейсу, базе данных и оперативным данным поможет вам избежать следующих ночных кошмаров:
- Медленная производительность
- Код связи Tedious Client Server
- Головная боль обслуживания
Какую платформу использовать (как сделать Direct Ajax)
После ознакомления с преимуществами Direct Ajax я хотел бы изучить доступные в настоящее время среды Ajax, чтобы определить, сколько из них удовлетворяет требованиям Direct Ajax.
Матрица сравнения
В приведенной выше матрице есть четыре платформы, которые поддерживают программирование на стороне сервера, а именно:
ZK ,
Backbase ,
Echo2 и Icefaces.
ZK , однако, превосходит другие с его полной поддержкой других функций, языка разметки, языка сценариев, загрузки по требованию и мобильной поддержки.
5 причин, по которым вы должны использовать Direct Ajax
Создание корпоративного приложения никогда не бывает легкой задачей, не говоря уже об обогащении его пользовательского опыта в то же время. Direct Ajax предназначен для того, чтобы помочь разработчикам выполнить проект вовремя, не работая сверхурочно. Вот пять причин, по которым вы должны использовать Direct Ajax.
- Повысить производительность разработчиков. Разработчики сосредотачиваются на самом приложении, а не на Ajax.
- Быстрое прототипирование . Пользовательский интерфейс и серверная часть приложения больше не разделены.
- Быстрое и простое обучение. Нет больше JavaScript, XMLHttpRequest.
- Безопасное общение. Отсутствие опасности раскрытия клиенту бизнес-логики и данных через Интернет.
- Простое обслуживание. Нет больше кода клиента.
Beyond Direct Ajax (вездесущий — мобильный)
В дополнение к вышеупомянутым преимуществам Direct Ajax, расширяемость приложения также весьма важна. ZK демонстрирует свою расширяемость, легко расширяя веб-приложение на телефоны Java и на платформу Android. С ZK вы можете запускать свои веб-приложения практически где угодно.
Об авторе
Он разрабатывает форум ZK и расширение ZK для Google Android. Он имеет опыт разработки приложений Ajax. Он также является автором ZK: Ajax без Javascript Framework.