Лучшая архитектура приборной панели

Question

Мне нужно создать панель мониторинга для приложения, панель мониторинга будет иметь разные панели управления, и каждая панель может иметь любую из следующих вещей:

1. Графики (JFreeCharts и некоторые Javascript Chart)
2. Данные таблицы из таблиц
3. Данные из внешних источников
4. Карты

Что может быть хорошей архитектурой для такого рода приложений?

Что я сейчас имею в виду:

1. Каждый дашлет должен иметь свой собственный жизненный цикл, и когда панель инструментов загружается, он должен сначала просто отображать интерфейс дашлетов.
2. После загрузки страницы каждый дашлет отправляет серверный вызов (в зависимости от его типа) для извлечения данных
3. После выборки данных каждый дашлет (в зависимости от его типа) отображает данные.

Answer 1

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

• Магистраль
• Javscript MVC
• Sproutcore

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

При всем этом основная проблема, которую вы поставили, на самом деле похожа нанаша.В конце концов, мы построили что-то немного другое в доме.Многие из этих структур оптимизированы для отображения единственного канонического «представления», основанного на модели, отраженной БД и контроллером для управления небольшими изменениями.В сущности, панель инструментов содержит множество различных модулей, которые должны выполнять свои собственные независимые действия, как вы упомянули в своем вопросе.Из-за большого количества независимых модулей, я чувствую, что вы можете испытывать трудности в некоторых из перечисленных выше фреймворков.

Я не могу точно сказать вам, как реализовать такую ​​архитектуру модулей, но вот некоторые правилабольшого пальца, который мы использовали при разработке наших:

Конструкция модуля:

• На основе модуля.(Модуль входа, модуль карты, каждый дашлет может быть модулем и т. Д.)
• Модули должны иметь одну модель, могут иметь не более одной коллекции (то есть модели) и могут иметь одну или несколькоПредставления.
• Модуль может использоваться в нескольких местах и ​​на страницах.Единственная модель должна оставаться прежней, но представления, вероятно, отличаются.

Рендеринг:

• Почти весь HTML на странице написан иобновлен модулями javascript.Файлы шаблонов почти пусты, за исключением заголовков и базовых скаффолдингов.
• Все модули отображают свое полное HTML-себя и заменяют себя в DOM.Модуль должен иметь как можно более полное статическое HTML-представление, готовое к работе перед вставкой в ​​DOM.Это означает, что функции рендеринга используют «.replaceWith ()» вместо «.append ()».
• Если простая замена HTML не является опцией (т.е. нуждается в анимации), следует определить функцию перехода, детализируякак перейти из одного состояния визуализации в другое.
• Поскольку рендеринг дорог, представления по умолчанию не обновляются автоматически при всех изменениях модели.Повторное рендеринг происходит только через события._render () фактически является внутренним методом.

Ортогональность:

• Один межмодульный диспетчер событий на странице Контроллер обрабатывает всеперекрестные эффекты между модулями.
• Модули никогда не должны «выходить за пределы» своего собственного контекста DOM.Если событие в одном модуле влияет на другой, оно должно проходить через диспетчер контроллера страниц.
• Каждый модуль должен быть максимально ортогональным.Они зависят друг от друга как можно меньше.
• Каждый модуль в отдельном файле.

Подключение к бэкенду:

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

Рекурсивный :

• Модули обычно включаются в другие модули.
• Модули выполняются рекурсивно.

Тестируемый :

• Поскольку модули отображают статический HTML, они могут быть предсказуемо протестированы.
• Модули должны быть тестируемыми.
  • Стандартный ввод -> Модуль -> Предсказуемый статический вывод HTML.
  • Стандартные события -> Модуль -> Предсказуемый статический вывод HTML.

Если кто-нибудь знает другие фреймворки в этом направлении, пожалуйста, поделитесь!

Answer 2

Наше веб-приложение основано именно на этой архитектуре и работает с конца прошлого года.Вы можете увидеть это на http://beebole.com

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

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

Answer 3

Я думаю, что вы ищете больше в управлении или контроле вашей панели. Я проектирую что-то подобное. Я бы посоветовал вам взглянуть на Google App Engine, который может быть использован для автоматизации и управления: https://developers.google.com/appengine/docs/whatisgoogleappengine

Также посмотрите на эти панели с открытым исходным кодом: https://github.com/twilio/stashboard

Answer 4

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

Как уже упоминалось в другом ответе, традиционные фреймворки в стиле MVC не очень хорошо соответствуют желаемому стилю пользовательского интерфейса вашей «панели мониторинга». Их лучше всего использовать для создания статических веб-сайтов на основе данных, полученных в других местах. Они плохо обрабатывают взаимодействие с пользователем, и вам, как правило, приходится вручную крутить собственный AJAX, чтобы сделать что-нибудь полезное без запроса страницы.

Лучшее поколение веб-фреймворков - это фреймворки Web 2.0, также известные как фреймворки, которые помогают создавать веб-приложений . Важно понимать разницу между веб-сайтом и веб-приложениями. Они обычно различаются тем, что последние интерактивны, а первые в основном статичны. Веб-сайты, которые также имеют некоторые интерактивные компоненты, по-прежнему являются веб-сайтами. Хороший способ думать об этом - спросить себя: «Это похоже на приложение для настольного компьютера?».

Для разработки веб-приложений в области Java (JVM) я бы использовал Vaadin . Это позволяет вам писать Java-код, похожий на программирование на Swing, с методами, основанными на событиях. Вы даже можете вообще отказаться от написания HTML, если захотите, определяя свои взгляды программно. Это позволяет вам тестировать логику представления (в веб-приложениях их больше, чем обычно), что невозможно с обычными основанными на шаблонах HTML-фреймворками. Другое главное преимущество состоит в том, что он имеет встроенные методы, которые позволяют вам писать код Java для обработки динамической, асинхронной функциональности, и все это автоматически переводится в JavaScript. При написании веб-приложения не нужно писать на 4 разных языках, просто напишите Java для всего! Попробуйте, с ним интересно работать!

Другой фреймворк веб-приложения, которому уделяется много внимания, - Lift . У меня нет опыта с этим, но многие разработчики, с которыми я говорил, продвинули его мне. Я считаю, что он использует шаблоны HTML с Java-кодом в качестве фоновой. Также, по-видимому, действительно легко начать работу, и ваше веб-приложение заработало. Он также имеет встроенную поддержку для выполнения AJAX-подобных функций. Стоит посмотреть хотя бы.

Вероятно, существует гораздо больше фреймворков для веб-приложений, которые бы соответствовали вашим потребностям. Все они имеют преимущество в том, что они тестируются, обслуживаются независимо, обновляются и безопасны *. Если вы катите свой собственный фреймворк для этого проекта, вам нужно обо всем позаботиться самостоятельно. Написанный веб-фреймворк, который не предлагает ничего нового, был бы похож на написанный еще один язык программирования, который не является инновационным; это просто трата времени.