Итак, в своей первой статья я сделал несколько предположений об архитектуре предметной области в CMF/CMS системах. Тогда я сделал предположение об объектной модели я связанном с нею сервисе, который умел обрабатывать входящие запросы и выдавать нужный результат на основании внутренней структуры модели.

Сегодня, сейчас, я бы хотел коснуться вопроса непосредственного использования такой системы в существующем фреймворке Mozart, не так давно впущенном компанией ADV под лицензией GPLv3.

Основой API Mozart'а служат newt-контейнеры. Newt — это XML-контейнер (в XML-фрагменте), который специальным образом обрабатывается XML-парсером. Newt может быть как одиночным тэгом (закрытым тэгом <newt />), так и контейнером (содержит в себе другие контейнеры (newt'ы, инструкции)). Аналог newt'а — это функция, задачей которой является произвести какие-то действия (и вернуть результат, если требуется).

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

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

Самые простые системы позволяют лишь организовать хранилище, к которому разработчик в дальнейшем обращается и делает всю необходимую работу по обработке данных сам. В таком хранилище есть лишь объект, поля и данные. В более продвинутых системах между объектами появляются связи. Следующий уровень развития — взаимодействие объектов (триггеры, методы и т.п.), а так же наличие программной подсистемы, снимающую с разработчика часть забот по обработке данных.

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