Тайбут

getee (https://gitee.com/magintursh/tyboot), github (https://github.com/magintursh/tyboot)

Введение

Тайбут — это серверный фреймворк на основе Spring Boot, предназначенный для быстрой разработки серверных приложений. Для микросервисной архитектуры рекомендуется использовать другой проект — тайклауд (всё ещё находится в разработке).

Особенности

1. Упрощение процесса разработки базовых функций. а. Не нужно писать SQL для запросов к одной таблице. б. В mapper-слое DAO достаточно оставить пустым интерфейсом, большая часть кода не требует написания кода в mapper (кроме сложных отчётов), а также не требуется XML-файл mapper. в. В baseService есть множество универсальных методов, которые можно использовать. Разработчикам не нужно писать код для операций с одной таблицей и одним объектом, а для разбиения на страницы и запросов достаточно одной строки кода. г. Рекомендуется использовать операции с одной таблицей. Не рекомендуется использовать сложные SQL-запросы для решения сложных бизнес-задач.
2. Снижение стоимости обучения. Новые сотрудники могут быстро приступить к работе, а новички с базовыми знаниями могут сразу же приступить к разработке бизнес-функций.
3. Интеграция популярных компонентов. Redis, MQ, события, MongoDB и т. д.
4. Реализация общей бизнес-модели. Готовые к использованию бизнес-модели могут значительно сократить время разработки проекта. Планируемые общие бизнес-модели включают:
   • систему управления заказами;
   • виртуальную систему счетов;
   • платёжный шлюз;
   • динамические формы;
   • системы отчётности;
   • общую систему бронирования;
   • настройку политики скидок;
   • базовые данные (проверка подлинности, словарь, внутренние сообщения, географическое положение, общая информация о файлах, операции и подсчёт).
5. Интеграция распространённых сторонних систем. SMS (Али Даюй), хранение (Qiniu, Али OSS), оплата (WeChat Public Platform, Alipay).

Технологический стек

• SpringBoot 2.1.6.RELEASE;
• MyBatis-Plus 3.x;
• mybatis-spring-boot-starter 1.2.0;
• Kaptcha 2.3.2;
• jackson-databind 2.9.7;
• springfox-swagger2 2.2.2;
• HikariCP 2.7.9.

Структура проекта

Tyboot
├─tyboot-api
│  ├─tyboot-api-boot                Пример проекта, реализующий общие функции, такие как управление словарями и разрешения.
├─tyboot-component
│  ├─tyboot-component-activemq      Интеграция ActiveMQ.
│  ├─tyboot-component-amqp          Простая интеграция Spring AMQP.
│  ├─tyboot-component-cache         Кэширование, дополнительная реализация и инкапсуляция Redis, географическое местоположение, конвейер, реализация разбивки на страницы Zset.
│  ├─tyboot-component-emq            Интеграция MQTT-сервиса EMQ.
│  ├─tyboot-component-event          Использование механизма событий Spring для реализации обработки событий на основе REST API.
│  ├─tyboot-component-mongo          Интеграция Mongo.
│  ├─tyboot-component-opendata      Интеграция общих открытых интерфейсов сторонних разработчиков, таких как Qiniu, Ali Duyun, Tencent IM, Megvii Push.
│  └─tyboot-component-validation      Проверка параметров.
├─tyboot-core
│  ├─tyboot-core-auth                Аутентификация пользователей и совместное использование сеансов.
│  ├─tyboot-core-foundation          Общие инструменты, такие как инкапсулированные потоки, контексты Bean и File, списки в деревья, шифрование и дешифрование.
│  ├─tyboot-core-rdbms                Интеграция MyBatis и MyBatis Plus, упрощение ORM и инкапсуляции сервисов.
│  └─tyboot-core-restful              Инкапсуляция RESTful API, документация по API, унифицированная обработка исключений, обработка перехвата запросов, инкапсуляция возвращаемых данных и контекста.
└─tyboot-prototype
    ├─tyboot-prototype-account        Система виртуальных счетов.
    ├─tyboot-prototype-order           Универсальная система управления заказами.
    └─tyboot-prototype-trade           Простая реализация платёжного канала, включая Alipay и WeChat.

Каталог соглашений:

Пример: tyboot-api-privilege — ниже приведена структура каталогов соглашения о проекте. org.typroject.api.privilege. controller — каталог интерфейса; face. — бизнес-слой; model — VO; orm. — операции с данными; dao — интерфейс mapper; entity — PO; service — реализация бизнес-логики.

Соглашение ORM:

1. Сущность должна наследовать BaseEntity. Соответствующая таблица данных не может отсутствовать общие поля. SEQUENCE_NBR — bigint 20 — физический первичный ключ; REC_USER_ID — varchar 32 — идентификатор последнего модификатора; REC_DATE — datetime — дата последней модификации.

2. Используется mybatisplus, поэтому в примере проекта не требуется импортировать файл mapper.xml, и базового метода baseMapper достаточно. Исключением является необходимость выполнения сложного запроса или импорта XML, который будет реализован в файле.

3. Обычно интерфейс dao слоя mapper пуст, за исключением случаев, когда необходимо написать SQL или импортировать XML, методы будут реализованы в нём.

Сервисное соглашение:

1. Наследовать baseService.

public class LocationInfoService extends BaseService<LocationInfoModel,LocationInfo,LocationInfoMapper> {}

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

3. В примере сервиса нет интерфейса, и используется непосредственно класс реализации. Необходимо определить интерфейс самостоятельно. При проектировании бизнес-системы следует придерживаться принципов проектирования. Для простых бизнес-систем можно гибко выбирать в зависимости от ситуации.

4. Операции с одной таблицей и одним объектом не требуют написания методов в сервисе, а также не требуют импорта mapper, универсальных методов достаточно, разбиение на страницы и запросы требуют только одной строки кода, например:

Разбивка на страницы:

public Page<DictionarieModel> queryDictPage(Page page, String agencyCode ,
                                               String buType,
                                               String dictAlias,
                                               @Condition(Operator.like) String dictName,
                                               String dictCode) throws Exception
{
    return this.queryForPage(page,"排序字段",false,agencyCode,buType,dictAlias,dictName,dictCode);
}

В качестве параметра запроса необходимо использовать имя атрибута, соответствующее имени атрибута модели. Передача параметров в список params в queryForPage в baseService должна соответствовать порядку параметров предварительного метода (queryDictPage)

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

Аннотация @Condition используется для определения оператора условия. Список уже реализованных операторов условий см. в Operator. Все логические отношения между условиями поиска представляют собой отношения «И», а отношения «ИЛИ» пока не реализованы.

Список: (соглашение о параметрах аналогично методу разбиения на страницы)

public List<DictionarieModel> queryDictList(String agencyCode, String buType, String dictAlias, @Condition(Operator.like) String dictName, String dictCode) throws Exception {
    return this.queryForList("排序字段", false, agencyCode, buType, dictAlias, dictName, dictCode);
}

Контроллер

1. Унифицированный возврат значений: все интерфейсы используют ResponseModel для упаковки возвращаемых значений.
2. Пользовательская аннотация @TycloudOperation используется для определения уровня доступа интерфейса ApiLevel и контроля авторизации needAuth.
3. Можно настроить, возвращать ли реальный статус HTTP или всегда возвращать 200.

О кэшировании

1. Кэширование отдельных объектов и списков объектов уже интегрировано в методы baseService. Вы можете обновлять или удалять кэш при обновлении объекта, подробности смотрите в комментариях к методам.
2. Для других сценариев кэширования рекомендуется напрямую использовать rediTemplate.
3. Модуль tyboot-component-cache предоставляет функции разбиения по страницам на основе redis Zset; географических вычислений и запросов; использования каналов redis.

Использование генератора кода

Используйте генератор кода, предоставляемый mybatisplus, см. пример проекта.

Лучшие практики

1. Упакуйте компоненты из tyboot-core и tyboot-components в пакеты и опубликуйте их в maven private nexus для централизованного управления. Затем ссылайтесь на них в каждом экземпляре проекта для разработки бизнес-проектов. Это сделает бизнес-код экземпляра более понятным, ускорит упаковку и позволит вам обновить версию tyboot в любое время.

Планы

• Доработать документацию.
• Доработать пример проекта.