Два дня назад ко мне на почту поступило интересное письмо от начинающего Siebelman-а, в котором он сетовал на то, что нигде не может получить полную картину об этой трехуровневой архитектуре. Я решил, что, конечно, коллеге нужно помочь и лучшим вариантом будет не писать в личку что да как, а создать отдельную статью в этом блоге. Все статьи, опубликованные до текущего момента, конечно подразумевают, что у читателя уже есть какой-никакой опыт работы с системой. Но в разделе «о блоге»  я писал, что одной из целей блога является: Ответить на вопросы, интересующие начинающих специалистов, помочь в освоении новых областей системы. А за свои слова я отвечаю Вася внатуре, так что приступим.

Конечно же данный вопрос нельзя обсуждать без рассмотрения самой популярной картинки:

3la_1

 

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

Уровень данных (Data Object Layer)

Это объекты базы данных, конкретно это таблицы. Таблица — первое базовое понятие, которое пожалуй понятно всем. Таблица — это средство для хранения данных. Есть такие штуковины — базы данных, там хранятся данных в таблицах. В любой более менее серьезной IT-системе обязательно есть база данных.
Еще одним объектом из уровня данных на рисунке изображен столбец. Что такое столбец надо объяснять? Столбец — это составляющая таблицы. Отношение между этими двумя объектами в IT-жаргоне называется crow’s feet (гусиные лапки). Дело в том, что оно реально похоже на гусиную лапку (или на куриную). Иначе это отношение обозначают M:1 (много-к-одному), то есть одна таблица может содержать много столбцов, но при этом один столбец может относиться только к одной таблице (быть в составе таблицы). Все просто.

Бизнес уровень (Business Object Layer)

Это уже посложнее. Смотрим на схему и видим отношения между уровнями. Таблице из уровня данных соответствует бизнес компонент из бизнес уровня. Бизнес компонент — это некое объединение атрибутов конкретной сущности (например есть сущность клиент или сущность адрес). Бизнес компонент (далее БК) основывается на одной таблице — базовой таблице для БК. Но при этом он может включать в себя и другие таблицы. Чтобы было понятней, нужно сразу рассказать. что такое поле бизнес компонента.
Как видим из схемы объект «Поле» бизнес уровня соответствует объекту «Столбец» из уровня данных. Поле в БК — тоже самое, что столбец в таблице. Вернемся к БК. Он основан на какой-либо таблице, но при этом он может содержать поля, которые соответствуют столбцам из других таблиц. Для этого в БК есть такое понятие как Join (специальный атрибут, в котором мы можем присоединять другие таблицы по ключу к основной и использовать столбцы из этих таблиц в полях данного БК). Зачем это нужно? Затем, что хранить все данные по конкретной сущности в одной таблице не всегда удобно. Например, у нас есть сущность «Сотрудник». Есть соответствующая табличка с основными данными по сотруднику, на ней основан БК. Но наш сотрудник должен сидеть в каком-то из офисов (представим, что их много). Можно расширить таблицу и добавить всю информацию по офису для сотрудника. А можно поступить иначе. Можно создать (или скорее всего она уже есть) отдельную сущность, которая будет содержать атрибуты офисов. А в таблице сотрудника создать только один новый столбец — «id офиса». После этого мы в БК сотрудника создаем join, в котором присоединяем таблицу с офисами по внешнему ключу «id офиса» и после этого мы можем в БК сотрудника создавать поля, которые будут основаны на столбцах таблицы с офисами. Тем самым мы избавились от дублирования данных в базе, при этом получив нужную информацию в рамках интересующей нас сущности.
В бизнес уровне появляется еще один объект, которому нет аналогов в уровне данных — бизнес объект (далее БО). Бизнес объект — это логическое объединение между БК с указанием каким образом они между собой связаны. Например, возьмем сущности клиента и адресов. Есть БК клиентов. В нем все клиенты компании. Есть БК адресов. В нем все имеющиеся адреса. В БО настраивается связь между этими двумя сущностями и в итоге при выборе конкретного клиента система сама отберет из все адресов только те, которые относятся к этому клиенту.

Уровень пользовательского интерфейса (UI Layer)

Вот и добрались до последнего уровня. По названию понятно, что эти объекты может увидеть пользователь. Пойдем слева направо. List Column (или это может быть control, если речь идет о форм апплете) соответствует полю в бизнес уровне и столбцу в уровне данных. То есть этот объект отображает на экране конкретное значение — атрибут сущности. Далее апплет. Он соответствует бизнес компоненту в бизнес уровне, то есть он отображает сразу набор атрибутов сущности. Апплеты делятся на два основных типа (есть еще редко используемые, их рассматривать не будем): лист апплет и форм апплет. Лист апплет выглядит как таблица и содержит набор строк — записей сущности (БК на котором основан апплет). Пример лист апплета представлен на рисунке:3la_2

Форм апплет отображает информацию по одной конкретной записи БК. Пример форм апплета:

3la_3

Двигаемся дальше. View или «Представление». Оно соответствует бизнес объекту. Представление — это текущее отображение того, что пользователь видит на экране. В каждый момент времени работы приложения Siebel оно отображает одно представление, которое состоит из набора апплетов. При этом апплеты могут быть основаны на разных сущностях, а могут и на одной. Если на одной, то например верхний апплет содержит список клиентов, а нижний (форм апплет) детальную информацию по тому клиенту, на котором установлен курсор в верхнем лист апплете. Если говорить о разных сущностях: верхний форм апплет содержит конкретную информацию по клиенту, а нижний лист апплет содержит список его адресов. При этом связи между этими сущностями заблаговременно были настроены в соответствующем бизнес объекте.
Screen или «Экран» (но все всегда говорят скрин) — это набор представлений, которые можно связать между собой чем-то общим. Например Скрин содержит набор представлений, каждое из которых тем или иным образом относится к клиенту. Верхний апплет каждого предсталвения содержит детальную информацию по клиенту, а нижние апплеты все разные: адреса, сведения о работе, информация о семье, история взаимодействий и т.д. При этом переключаться между представлениями можно по вкладкам, которые отображаются между верхним и нижним апплетом. Скрин уже не имеет соответствующего объекта в бизнес уровне.
Последний объект на нашей схеме — Application или «Приложение». Можно сказать очень коротко и просто: Приложение — это набор скринов. В представлениях объединяем связанные друг с другом сущности и выводим пользователю. В скринах мы делаем более обобщенное объединение, которое может быть построено вокруг какой-то сущности. В приложение мы накидываем набор скринов, который содержит ту функциональность и информацию, которая нужна пользователю, работающему в этом приложении.

Пожалуй это все, что я хотел рассказать по этому поводу. Если остались вопросы, пишите в комментариях, с удовольствием отвечу!

 

UPDATE

По просьбе читателей постараюсь еще раз пояснить некоторые моменты.
1) Зачем вообще нужна трехуровневая архитектура?
Чтобы в полном объеме понимать ее назначение, нужно иметь общие представления о программировании, в особенности об объекто-ориентированном программировании (ООП). ООП — это парадигма программирования. Кратко можно сказать так: можно писать код как захочется, лишь бы добиться результата. В итоге программа будет работать, но скорее всего работать она будет плохо: будет кушать много памяти, грузить процессор, работать не оптимально. Парадигмы программирования задают некие правила написания и их структуры, что позволяет формализовать и упорядочить их разработку и функционирование. Помимо парадигм программирования существуют еще паттерны программирования (или проектирования). Они преследуют ту же цель, но еще более четко и конкретно. Использование этих инструментов в настоящее время является обязательным, если речь идет о хоть немного серьезной программе (а не о лабораторке студента). У Oracle Siebel CRM есть свое решение, которое упорядочивает объекты по типу и назначению: данные, логика, визуализация. На самом деле во всех современных IT-системах всегда есть разделение на визуализацию и логику (front и back). Эти части могут быть написаны на разных языках программирования и в большинстве пишутся разными людьми (front-end разработчиками и back-end). Похожая ситуация и в Siebel. Но дополнительно back часть разделена на логику и данные. Плавно переходим ко второму вопросу.

2) Смысл разделения busines layer и data layer.

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

Уровень данных — это просто таблицы, куча таблиц без чего-либо интересного. И на этом уровне важными задачами являются:

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

Что же касается бизнес уровня, то тут гораздо больше всего интересного. Попробую перечислить несколько пунктов:

  • Связь нескольких таблиц из уровня данных в рамках одной сущности с целью консолидации нужной информации
  • Установка отношений между разными сущностями. Предположим у нас есть две сущности. Каждая из них содержит данные из нескольких таблиц. Мы зададим только одно отношение между этими двумя сущностями. И нам не придется делать немыслимое количество связей между всеми таблицами.
  • На бизнес уровне для атрибутов (полей) сущностей (бизнес компонентов) можно задавать справочники значений, чтобы значение выбиралось из списка
  • На бизнес уровне можно устанавливать для полей предопределенные значения (то есть при созднании новой записи некоторые поля уже предзаполнены)
  • На бизнес уровне можно в прописывать условия, при которых какие-то из полей будут не редактируемы (например в зависимости от роли сотрудника ему можно или нельзя редактировать какой-то атрибут)
  • На бизнес уровне можно обрабатывать ряд событий, происходящих с сущностью (создание новой записи, запись значения в конкретное поле, удаление записи и т.д.), и при этом выполнять необходимые действия разнообразнейших видов (проверка действительности паспорта при вводе данных в поля с паспортными данными, отправка пробного email-а при указании адреса электронной почты и вообще все, что угодно)
  • и т.д.

Мы видим, что область деятельности бизнес уровня намного обширней, чем у уровня данных и она абсолютно другая.