Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

О кастомизации информационных систем

Anna | 2.06.2014 | нет комментариев
Основное направление деятельности нашей компании — это разработка корпоративных информационных систем. Помимо систем под заказ мы делаем два тиражируемых продукта. Безусловно, мы усердствуем, Дабы наши продукты были максимально комфортными и функциональными. Впрочем в реальной жизни всякий бизнес имеет свои особенности и не неизменно готов мириться со стандартными вероятностями системы. Появляется задача доработки решения под определенного заказчика и его последующей поддержки. Какие существуют подходы к организации архитектуры расширяемых продуктов? Какие задачи могут появиться при разработке? Как поступили мы? Обо каждому этом ниже.

Допустимые подходы

Для начала уточним, что «планом-растяжением» либо легко «растяжением» мы называем продукт с внесенными модификациями для определенного клиента. А сейчас разглядим некоторые из допустимых подходов к растяжению продукта:

Обособленный бранч в репозитории под всякий план-растяжение

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

Позже разработки и внедрения информационной системы начинается самая длинная и Зачастую самая болезненная фаза жизненного цикла — помощь. В случае с планом-растяжением эта фаза может стать вдвойне неприятнее, чай придется поставлять клиенту не только новые “фичи”, которые реализованы намеренно для него, но и новые версии продукта, на котором основано растяжение. Для того, Дабы в план попали метаморфозы из новой версии продукта, видится один метод — merge изменений из стержневой ветки в бранч растяжения. Но представьте, насколько это окажется трудоемко, и сколько возможных ошибок может проявиться, если один и тот же участок кода крепко изменялся в обеих ветках.

Дозволено, безусловно, сразу думать о грядущих переводах на новую версию продукта и организовывать код таким образом, что все специфичные метаморфозы будут располагаться максимально в стороне от кода основного продукта. В совершенном мире это бы сработало, но мы с вами живем в грозной действительности, где Зачастую срок выполнения задачи может быть объявлен как “вчера”, и работает над планом отнюдь не суперкомпактная команда изумительных специалистов, а батальон вчерашних студентов. В таких обстановках люди редко задумываются об архитектуре и идут по пути наименьшего сопротивления — обнаружил место, где нужно исправить, удалил ветхое, написал новое. Это, кстати, ведет к еще одной огромный задаче — логика растяжения перемешивается с логикой продукта.

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

Применение динамических признаков (модель Entity-Attribute-Value)

Модель Entity-Attribute-Value (либо Open Schema) может применяться совместно со стандартной реляционной моделью для динамического определения и хранения значений новых признаков сущностей. При применении модели EAV значения признаков традиционно пишутся в одну таблицу из 3 колонок. Как нетрудно додуматься, их имена Entity, Attribute и Value:

  • Entity — хранит ссылку на объект, поле которого мы описываем. Традиционно это идентификатор сущности;
  • Attribute — ссылка на определение признака (об этом ниже);
  • Value — собственно значение признака.

Непременным компонентом схемы является также таблица, которая хранит изложение метаданных для признаков:

  • тип признака;
  • ограничения (длина поля, регулярное выражение, которому должно соответствовать значение и пр.);
  • компонент для отображения в UI;
  • порядок отображения компонента в UI.

Для применения этой модели в продукте нужно сделать 2 вещи:

  1. Реализовать механизм задания метаданных, с поддержкой которого мы сумеем, скажем, указать, что к сущностям типа “Договор” добавится новейший признак «Дата расторжения», тип поля — «Дата», компонент для отображения — DateField.
  2. Реализовать механизмы отображения и ввода значений динамических признаков на нужных экранах продукта. Механизм должен находить допустимый комплект признаков для данной сущности в таблице с изложением метаданных, отображать компоненты для их редактирования, а после этого в таблице с данными искать и отображать их значения, сберегая их при закрытии экрана.

Самое основное превосходство подхода — это неимение необходимости создавать план-растяжение. Клиенту поставляется базовый продукт и на этапе настройки либо даже эксплуатации заводится всякое число динамических признаков в сущностях.

Дальше о недостатках. Во-первых, это сжатость использования. Модель EAV дозволит лишь добавить признаки в сущность и отобразить их в предварительно определенном месте на экране. Не больше того. Об изменении функциональности, хитроумных UI-компонентах тут речи не идет.

Во-вторых, EAV модель создает огромную дополнительную нагрузку на сервер БД. Для загрузки одного экземпляра сущности без связей понадобится чтение взамен одной нескольких строк таблицы. Для загрузки списка экземпляров, скажем в таблицу на UI, вообще понадобится N 1 запросов, либо джойны по числу колонок таблицы. Рассматривая, что база данных в корпоративных системах и так Почаще каждого является самым неторопливым и нехорошо масштабируемым элементом, такая добавочная нагрузка может легко убить систему.

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

Плагинная зодчество

Данная зодчество разрешает беречь дополнительную функциональность в отдельных артефактах — плагинах. Если ваш клиент хочет какой-то новой специфики, то вы ставите ему базовый продукт, пишете плагин, подключаете его и готово. Для применения плагинов в продукте обязаны быть объявлены точки растяжения. Что это такое? Если легко, то это определенные места в коде. В этих местах перебираются загруженные плагины, анализируется, есть ли в плагинах логика, предуготовленная для данной точки растяжения, и если такая логика находится, она выполняется. Примеры точек растяжения: пункт меню, обрабочик команды, кнопка на тулбаре, новейший экран.

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

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

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

Как это делаем мы

Мы выпустили на рынок два тиражируемых продукта: ECM (либо в больше знакомых терминах, систему электронного документооборота, СЭД) ПРИНЦИП и систему для автоматизации бизнеса такси Sherlock. С самого начала было видимо: для того, Дабы поставить определенному заказчику максимально комфортную систему, понадобятся доработки продукта, и следственно в основе продукта должна лежать легко расширяемая зодчество.

Начиная работу над новым растяжением, Зачастую мы даже не полагали, в какого «монстра» (в отличном смысле слова) данный план может перерасти. Обыкновенное явление — когда то, что начиналось как маленькая кастомизация, заканчивается фактически всецело переписанными бизнес-процессами и дополнительной логикой на добродушной половине экранов. Вдобавок продукт может расшириться новой функциональностью, абсолютно довольной для независимой системы. Как пример — в плане-растяжении ПРИНЦИП для большой распределенной компании возникла автоматизация деятельности казначейства, оценки результативности работы работников и еще несколько непростых модулей.

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

Как же мы решаем задачу создания и поддержки растяжений?

Наш план-растяжение

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

Если коротко, то CUBA — это комплект модулей, всякий из которых предоставляет определенную функциональность:

  • cuba — ядро приложения, содержит в себе всю инфраструктуру, средства для организации бизнес-логики, библиотеку визуальных компонентов, подсистему безопасности и пр.
  • reports — подсистема генерации отчетов
  • fts — подсистема полнотекстового поиска
  • charts — подсистема итога диаграмм
  • workflow — подсистема управления бизнес-процессами
  • ccpayments — подсистема работы с кредитными картами

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

При создании нового плана, в его скрипте сборки прописываются зависимости от тех базовых модулей платформы, функциональность которых нужна. Позже этого, применяя сущности, экраны и сервисы подключенных модулей, мы начинаем реализовывать план. Физически модули платформы — это jar файлы, а установленный на сервере план — обыкновенное Java веб-приложение.

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


Сейчас внутри плана-растяжения дозволено создавать новые объекты доменной модели, описывать новейший пользовательский интерфейс как в самом обыкновенном плане на платформе CUBA. Каждый функционал ниже-лежащих модулей разработчику по бывшему доступен.

Самое явственное превосходство — каждая новая логика хранится в отдельном плане-растяжении. Неизменно дозволено увидеть, что именно и когда вы написали в рамках нынешнего растяжения. Подход никак не ограничивает разработчика в типе новой функциональности, как это делают плагинная зодчество и EAV.

Процесс перевода растяжения на новую версию продукта заключается в дальнейшем:

  • вы указываете новую версию продукта в скриптах сборки и пересобираете растяжение;
  • если в растяжении применялся только стабильный API продукта, то на этом все — запускаете свой расширенный продукт и вперед;
  • если в продукте случились существенные метаморфозы в тех точках, которые вы расширяли, то может понадобиться метаморфоза кода растяжения. Как правило, это происходит нечасто, и локализовать задачу легко. Багфикс-релизы продуктов неизменно сберегают совместимость с растяжениями.

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

Добавление нового признака в сущность базового продукта

Определим для себя задачу: в сущность User базового продукта нужно добавить поле дmark!Вовсе не хочется дублировать код базового экрана в плане-растяжении, следственно мы добавили в платформу вероятность наследования XML-дескрипторов экранов. Вот так выглядит преемник экрана из базового плана:

<window extends="/com/haulmont/cuba/gui/app/security/user/edit/user-edit.xml">
    <layout>
        <fieldGroup id="fieldGroup">
            <column>
                <field id="address"/>
            </column>
        </fieldGroup>
    </layout>
</window>

В экране-преемнике указывается прародитель (признак extends) и описываются лишь те компоненты, которые обязаны быть добавлены в базовый экран либо переопределены в нем. Остается лишь объявить экран в конфигурационном файле с идентификатором базового экрана:

<screen id="sec$User.edit" template="com/sample/sales/gui/extuser/extuser-edit.xml"/>

Итог:

Переопределение бизнес-логики

Что касается переопределения функциональности, то тут все довольно банально. Инфраструктура платформы реализована на Spring. Соответственно и слой сервисов с бизнес логикой — это управляемые спрингом бины. Вероятностей растяжения, предоставляемых фреймворком, оказывается больше чем довольно для переопределения требуемой бизнес-логики. Дабы наглядно это продемонстрировать, вновь маленький пример. Возможен, на среднем слое в базовом продукте имеется компонент, исполняющий расчет цены:

@ManagedBean("product_PriceCalculator")
public class PriceCalculator {
	public void BigDecimal calculatePrice() { 
		//price calculation
	}
}

Для того, Дабы в плане-растяжении заменить алгорифм расчета цены мы делаем 2 примитивных шага:

Создаем преемника переопределяемого компонента:

public class ExtPriceCalculator extends PriceCalcuator {
	@Override
	public void BigDecimal calculatePrice() { 
               //modified logic goes here
	}
}

Регистрируем класс в конфигурационном файле Spring с идентификатором бина из базового продукта:

<bean id="product_PriceCalculator"/>

Сейчас контейнер Spring будет неизменно возвращать нам экземпляр ExtPriceCalculator.

Переопределение темы

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

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

Для реализации веб-UI нами был выбран знаменитый фреймворк Vaadin. Vaadin разрешает описывать темы на SCSS. Изложение жанров для новой темы на SCSS само по себе в разы славнее, чем на чистом CSS. Мы сделали процесс создания темы еще менее трудоемким, перенесши уйма параметров в переменные.

Заготовка для новой темы создается в 2 клика с поддержкой нашей студии разработки. Новая тема импортирует жанры базовой темы платформы, разработчику остается переопределить лишь надобные жанры и переменные. Многие заказчики желают видеть информационную систему в корпоративных цветах своей компании. Применяемый нами подход к растяжению тем разрешает им легко этого добиться.

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

Примеры разных визуальных тем:

Завершение

Если наш подход показался вам увлекательным, то можете испробовать платформу CUBA сами. Создавая продукт на платформе, вы механически получаете вероятность кастомизировать его описанным методом. Неизменно рады отзывам и комментариям!

P.S. Автор заглавного фото — Илья Варламов. Еще огромнее роскошных пакистанских грузовиков вы можете обнаружить в его блоге.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB