Архитектура приложения

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

     Архитектура программного обеспечения (ПО) заключает в себе ряд важных решений об организации программной системы, среди которых:

• выбор структурных элементов и их интерфейсов, со­ставляющих и объединяющих систему в единое целое;
• поведение, обеспечиваемое совместной работой этих элементов;
• организация этих структурных и поведенческих элементов в бо­лее крупные подсистемы;
• также архитектурный стиль, которого придерживается данная орга­низация (ЭкоСофт).

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

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

     Основные слои:

• слой представления, являющийся внешним отражением системы или интерфейсом пользователя;
• бизнес-слой, являющийся носителем логической структуры сис­темы или бизнес-объектом;
• слой доступа к данным (сериализатор).

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

     Цель архитектора ПО при проектировании приложения или системы – максимальное упрощение дизайна через его разбиение на функциональные области. Например, пользовательский интерфейс (user interface, UI), выпол­нение бизнес-процессов или доступ к данным – все это разные функциональ­ные области. Компоненты в каждой из этих областей должны реализовывать данную конкретную функциональность и не должны смешивать в себе код разных функциональных областей. Так в компонентах UI не должно быть кода прямого доступа к источнику данных; для извлечения данных в них должны использоваться либо бизнес-компоненты, либо компоненты доступа к данным.

     Основные практические требования:

• всю бизнес логику реализовывать в бизнес-слое (не вытаскивать в интерфейс);
• особенности поведения интерфейса реализовывать в слое представления;
• не использовать механизмы прямого доступа к данным, минуя биз­нес- слой (сводить к минимуму).

     Концепция бизнес объектов в ОРП Лексема 7.0

     ORM (Object-relational mapping) система есть объектно-реляционная модель представления данных.  Иными словами это означает, что данные для оперирования предоставляются в виде сформированных логических сущно­стей, отличных от таблиц, являющихся связанными с последними посредст­вом маппинга - прямого сопоставления поля объекта полю таблицы. ORM Лексема 7.0 расширяет идею ORM до системы проектирования бизнес-сущно­стей (структура + данные + поведение) с возможностью автоматического проецирования на СУБД.

     Бизнес-объект – есть целостное логическое представление взаимосвя­занных данных в виде единой сущности, с описанием методов, событий и ре­акций на модификацию данных. Методы, события и реакции сущности, по сути, есть описание ее поведения в тех или иных ситуациях и являются од­ним из ключевых моментов бизнес-логики. БО – это целостное логическое представление взаимосвязанных данных в виде единой сущности, с описа­нием методов, событий и реакций на модификацию данных. Данная сущ­ность многомерна и не является плоской. В реализованном виде БО пред­ставляет собой класс, содержащий поля, свойства, методы. Поля являются хранителями данных и представляются типом других БО и таким образом получается некое дерево являющееся единой сущностью. Методы реализуют логику работы БО. А свойства позволяют вызвать реакцию на модификацию данных и являются посредником между сериализатором и интерфейсом. Свойства являются точкой отсчёта момента изменения данных.   

  Средством ОРП является реализованный отдельный программный мо­дуль, позволяющий преобразовывать объектные данные в реляционные и на­оборот. Механизм ОРП позволяет проецировать БО на таблицу, а свойство на поле в таблице, дочерние коллекции в отдельную таблицу, формировать ключи, триггеры и строить индексы. Благодаря ОРП программист избавля­ется от этапа проектирования БД. Структура базы данных строится автома­тически сериализатором, проецируя БО с приведением  соответствующих ти­пов в языке программирования и СУБД. Платформа Лексема 7.0 достаточно удачное решение на рынке ОРП систем.

     Для работы с данными существуют бизнес объект. БО – класс LxBusi­nessObject, позволяющий работать с данными в двух направлениях (запись и чтение). Проектирование базовых возможностей системы решается путём соз­дания БО, так как он несёт в себе структуру и связанную с ней логику. Сам процесс проектирования структуры БО схож с процессом проектирования БД, доводя его до необходимой нормальной формы. Структуру данных со­ставляют классы со своими свойствами. Динамика бизнес процесса реализу­ется в свойствах и процедурах.

     В контексте проектирования БО – это логическая единица бизнес про­цесса, которая может быть обособленна, формализована и описана в инфор­мационной системе. Формализация объектов происходит в рамках концепции ООП. Архитектура Лексемы такова, что все ключевые события в проекти­руемой системе инициализируются пользователем системы. В роли пользо­вателя могут выступать люди и сервисы. (Например, продажа билетов: покупатель, билет, событие, место.)