BeanExplorer5 — различия между версиями

Версия 17:44, 10 мая 2016

Это основная статья о BeanExplorer5.

Поскольку эта основная статья недописана, остальная её часть для тех, кто будет дорабатывать BeanExplorer5, а не использовать.

Концепции

Основные технологии, которые мы используем - это Java, Java Servlet, OSGi, React, SystemJS, ES2015 через Babel.

Frontend

Основные frontend компоненты написаны на React, но могут быть написаны на чём угодно. Поскольку React - это лишь "V" из MVC, то часть функционала полноценного frontend framework было необходимо реализовать, и этот функционал находится в be5/be5-frontend/src/scripts/be5.js (или просто be5 - далее буду писать имена скриптов кратко). Это покрывает функционал routing, requests, frontend localization. Также полезный базовый функционал находится в be5/bus, be5/createStore, be5/createSimpleStore, be5/ext.

• bus - сообщения (брокер из паттерна pub/sub); например, bus.fire('DocumentChange', value), bus.listen('DocumentChange', value => ...);
• ext - расширения;
• createStore - создание store для управления данными на frontend; позволяет подписаться на его изменения;
• createSimpleStore - создание store, полным состоянием которого является результат GET запроса.

Необходимые части frontend подгружаются динамически с помощью SystemJS.

JSX+ES2015 скрипты компилируются с помощью Babel при сборке проекта.

Нерешённые проблемы:

• frontend подготовлен, но не переведён на redux, а это необходимо для упрощения работы с React компонентами (без redux или Flux бывает довольно нетривиально управлять состоянием React компонентов);
• be5.js требует разделения на небольшие части, также, как выделены bus и ext;
• невозможно отказаться от компиляции ES2015, даже если она будет поддерживаться всеми браузерами. SystemJS проверяет наличие ES2015 синтаксиса в скриптах, и в случае его наличия потается использовать транслятор в браузере, даже если явно указано, что транслятора нет

Tips на будущее:

• используйте redux, React two-way binding, React classNames.

Backend

Основные части API находятся в com.beanexplorer.enterprise.api. Проще всего начать знакомство с BE5, посмотрев на содержимое этого пакета и его подпакетов. В com.beanexplorer.enterprise.api.experimental.v1 хранятся маленькие полезности. Если они становятся не экспериментальными, а доказавшими полезность, можно переносить их в другие подпакеты api. v1 в названии пакета необходимо для поддержки разного API для одинакового функционала, если невозможно быстро отрефакторить код с экспериментальным функционалом или если хочется проверить, какой подход окажется полезнее.

Сердце всего BE5 - это ServiceProvider. ServiceProvider доступен компонентам, а в конструкторы сервисов инжектируются другие сервисы или сам ServiceProvider.

Good practices:

• Разделяем модельные элементы на бины без логики, сервисы и репозитории.
• Презентационный код пишется в компонентах. Если в компоненте много строчек кода, то что-то пошло не так.

Нерешённые проблемы:

• При написании operation почти любая строчка кода приводит к увеличению зависимости от наличия метаданных в БД, а также ухудшению возможности что либо протестировать, равно как и невозможности переиспользовать написанный код. Необходимо новое API для операций, полагающееся на сервисы - содержимого com.beanexplorer.enterprise.api.experimental и com.beanexplorer.enterprise.api.experimental.v1 недостаточно.
• Нет предусмотренного сетапа для тестирования.
• Нет API для запросов из БД, которое покрывает все возможные SQL запросы.

Tips на будущее:

• Можно ресширить функционал ServiceProvider добавлением способности обрабатывать аннотированные поля сервисов - это избавит от проблем обхода циклических зависимостей сервисов и написания boilderplate в конструкторах. Также возможно попробовать сэмулировать поведение из Spring Core или Google Guice - это бы позволило просто перйти на них при возможности (см. следующее).
• Можно даже использовать Google Guice или переиспользовать Spring Core, если найдётся хороший способ регистрации сервисов из разных OSGi модулей (сам BE5 и BE5 приложение - в разных OSGi модулях).
• В идеальном случае было бы хорошо не писать репозитории, да и сервисы для запросов - для этого есть Hibernate, реализации JPA и другие ORM. А ещё лучше - попробовать переиспользовать Spring Data (объявлять интерфейсы с методами, описывающими запрос, без необходимости писать сам код запроса - как personRepository.findByEmailAndActive("email", true) - вызов метода из интерфейса, реализацию которого подкладывает Spring).
• Или хотя бы доделать SQL builder (SqlBuilder) и SQL Service (SqlService), потому что они сейчас не позволяют делать запросы с LEFT JOIN и WITH RECURSIVE.

Сборка BeanExplorer5

См. Сборка BeanExplorer5 проекта.

BeanExplorer5 API

См. BeanExplorer5 API