Архитектура CMS. Модель данных. Часть 1

    Система управления содержимым (CMS) обязана предоставить гибкие всеохватывающие функциональные возможности для управления содержимым сайта, облегчить работу администратора-конфигуратора и способствовать созданию удобного в использовании сайта. Содержимым сайта можно назвать новости, размещенные на нём, а также статьи, комментарии, фотографии. Содержимым также являются целые структуры информации: новостные ленты, каталоги, форумы, блоги. Обобщенно: содержимое – это данные, размещенные на сайте.

    CMS может просто передавать данные по запросу клиентскому приложению, например сетевой программе, flash-клипу или AJAX-приложению. Но чаще всего, CMS предоставляет клиенту уже подготовленные для отображения данные в HTML формате. В этом случаи, для обеспечения доступности, легкости восприятия и удобства пользования содержимым, выполняется стилизация и объединение его с элементами оформления (темы, шаблоны), навигации (меню, ссылки) и управления (формы и ссылки тоже), и всем этим тоже нужно управлять.

    Идея


    Окружающий мир воспринимается нами объектным, мы мыслим «объектами», в наших умах выстраивается объектная модель мира. Поэтому нам не составит труда создать объектную модель содержимого сайта и управлять ею. Новости, товар в каталоге, сообщения на форуме и сами форумы, и все другое можно представить в виде объектов. Устанавливая связи между объектами, можно создавать структуры данных любой сложности, от добавления комментариев к статьям до создания социальных сетей и более.

    Объекты, классы и связи данных – это информация, которую нужно уметь создавать, хранить, использовать, изменять и удалять. В нашем распоряжении реляционная база данных для хранения информации. Действия же совершаемые с информацией – часть логики функционирования CMS, которая в большей части будет реализована модулем данных Data. Речь идет о создаваемой CMS Boolive. Предыдущая статья про архитектуру CMS.

    Фактически модуль данных будет осуществлять объектно-реляционную проекцию (ORM) – предоставлять объектно-ориентрованный доступ к базе данных. При этом сущности объектной модели (классы, связи, объекты) будут определяться в базе данных, а не программно, что позволит, не программируя, создавать новые классы данных – новые типы содержимого.
    Чтобы не путаться с объектами и классами языка программирования, применяются термины «объект данных» и «класс данных»
    Для хранения однотипных объектов в реляционной базе данных в принципе достаточно одной таблицы, поля которой будут соответствовать атрибутам объекта. Но объекты могут иметь связи на другие объекты и чаще только их и имеют. Вместо того, чтобы в таблице объектов создавать поля (внешние ключи) для связи с другими объектами, лучше создать отдельную таблицу для связей – это, кстати, позволит хранить дополнительные сведения о связях, в частности, именование и их тип. Связь образует свойство у объекта, владеющего связью. Свойством называется совокупность связи и объекта, на который установлена связь.

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

    Каждая сущность (класс, объект и связь) должна иметь идентификатор – уникальное целое число, уникальное среди всех сущностей. То есть не должно быть, например, класса и объекта с одинаковым идентификатором. Уникальность идентификатора среди разнотипных сущностей позволяет, в частности, хранить связи классов в таблице вместе со связями объектов. Термин «сущность» подразумевает и объект, и класс, и связь.

    Одно из основных понятий объектной модели – наследование классов. Наследование тоже нужно представить в реляционном виде и это достаточно легко сделать, определив целочисленное поле в таблице классов для хранения идентификатора наследуемого класса (внешний ключ), и оперировать этой информацией для слияния соответствующих таблиц объектов при запросах. Если класс «B» наследует класс «A», то атрибуты объектов класса «B» будут храниться в таблице «А» и «Б».

    Классы являются объектами! Пока без объяснений. Так как класс – это объект, а у любого объекта имеется класс, значит и у класса есть класс, определяющий атрибуты для него, в частности имя и идентификатор наследуемого класса. Связи тоже являются объектами, соответственно и они имеют свой класс. Таким образом, всё является объектами, но чтобы не путаться с назначениями разнотипных объектов, в целях обобщения будет применяться термин «сущность».

    Реализация


    Итак, исходя из всего изложенного, каждая сущность обладает идентификатором и классом, точнее связью на класс. Приступим к реализации и для всех сущностей создадим таблицу с названием «id». В таблице два поля – идентификатор сущности и идентификатор класса сущности. Мы создали (пока ещё не полностью) базовый класс «сущность» – все остальные классы обязаны будут наследовать класс «сущность» иначе смысла в их создании не будет.

    CREATE TABLE `id` (  
      `id` int(10) unsigned NOT NULL auto_increment,  
      `class` int(10) unsigned NOT NULL,  
      PRIMARY KEY  (`id`),  
      KEY `index_class` (`class`)  
    );
    


    Создаем второй класс с названием «class». Пока создание класса сводится к созданию таблицы. Создаем таблицу с именем «class» и полями «id», «sys_name», «extend», «final». Поле «id» используется для связи «один к одному» с таблицей сущностей, поле «id» используется логикой системы для слияния записей при реализации наследования. «sys_name» – это системное имя класса, совпадающее с именем таблицы, в которой будут храниться объекты соответствующего класса. «extend» – идентификатор наследуемого класса. «final» – признак возможности наследования класса (если 0).

    CREATE TABLE class (  
        `id` int(10) unsigned NOT NULL,  
        `sys_name` VARCHAR(255) NOT NULL,  
        `extend` int(10) unsigned NOT NULL default '1',  
        `final` tinyint(1) unsigned NOT NULL default '0',  
        PRIMARY KEY  (`id`),  
        UNIQUE `index_sys_name` (`sys_name`)  
    );
    


    Сейчас понять картину взаимосвязей будет непросто – это как случай с курицей и яйцом, типа, что было первым? В данном случае даже ошибочно рассказывать появление двух сущностей (классов) последовательно, так как они должны появиться одновременно и не могут существовать друг без друга.
    Созданы две таблицы – как бы созданы два класса, но именно как бы, так таблицы пусты – сущностей нет. Первая сущность – это базовый класс «id» называемый «сущность». От того, что сущность эта является классом, ассоциируемая с ней запись должна быть как в таблице «id» так и в таблице «class». Идентификатор первой сущности равен 1. Обратите внимание на системное имя класса – оно совпадает с именем таблицы «id». Вторая сущность тоже является классом, поэтому запись тоже и в таблице «id» и в таблице «class». Системное имя второго класса «class» совпадает с именем таблицы созданной для классов. Второй класс наследует первый – это определено в поле «extend». Второй класс запрещено наследовать.

    Таблицы «id» и «class»
    Теперь обратим внимание на поле «class» в первой созданной таблице. Обе сущности определяются классом с идентификатором 2. Да, именно так! Первая сущность определяется классом 2, поэтому она является классом, у неё определены все атрибуты характерные классам. Вторая сущность, тоже является классом и наследует первый класс, поэтому объекты класса 2 имеют идентификатор и связь на класс. Проанализируйте взаимосвязи, посмотрите, как все лаконично само себя определяет – и таблицы и атрибуты и то, что обе сущности являются классами.

    Создадим теперь класс для связей. Класс-связь определяет атрибуты специфичные для связей:
    • «sys_name» – системное имя связи;
    • «define» – идентификатор связи, определяющей данную связь;
    • «kind» – признак вида связи: «использовать» или «состоять»;
    • «size» – признак мощности связи: «много» или «один»;
    • «is_define» – признак, что связь определяет связь между объектами;
    • «is_mandat» – признак, что связь обязательно должна быть у объекта;
    • «primary» – идентификатор сущности владельца связи;
    • «secondary» – идентификатор сущности, с которым выполняется связь.


    CREATE TABLE `link` (  
      `id` int(10) unsigned NOT NULL,  
      `define` int(10) unsigned NOT NULL default '0',  
      `sys_name` varchar(255) NOT NULL,  
      `kind` tinyint(1) unsigned NOT NULL default '0',   
      `size` tinyint(1) unsigned NOT NULL default '1',  
      `is_mandat` tinyint(1) unsigned NOT NULL default '1',  
      `is_define` tinyint(1) unsigned NOT NULL default '1',  
      `primary` int(10) unsigned NOT NULL,  
      `secondary` int(10) unsigned NOT NULL,  
      PRIMARY KEY  (`id`),    
      KEY `index_define` (`define`),    
      KEY `index_sys_name` (`sys_name`),  
      KEY `index_primary` (`primary`),  
      KEY `index_secondary` (`secondary`)  
    );
    


    Связи имеют двойное назначение, используемое логикой модуля Data. Первое назначение – непосредственная связь между объектами для реализации свойств, второе назначение – определение этих свойств классом. Класс, установкой связи с другим классом, определяет свойства для своих объектов. Но если рассматривать класс как объект, то он тоже может иметь свойства. Значит простым наличием связи между классами нельзя определить, что эта связь описывает свойство у объектов. Поэтому у связи имеются атрибуты «define» и «is_define». По атрибуту «define» можно найти связь между классами, определяющею данную связь. Атрибут «is_define» является признаком, принимающим значение 0, если это обычная связь между объектами и 1, если эта связь описывает свойство и применяется классом.

    Связи бывают двух видов: «использовать» (агрегация, ассоциация) или «состоять» (композиция, быть частью). Вид определяется атрибутом «kind». Объекты, связанные с другим объектом связью вида «состоять» и являющиеся подчиненными, будут зависеть от объекта-владельца связи. Зависимость сводится к тому, что удаляя главный объект, будут автоматически удаляться все подчиненные объекты связанные связью вида «состоять». Есть другие особенности, например объект не может «быть частью» более чем для одного объекта.
    Связи второго вида – вида «использовать» сохраняют независимость связанным объектам. Без ограничений и последствий может быть независимо удален как объект владелец свойства, так и объект являющийся свойством. Объект может «использоваться» любым количеством объектов.

    Если бы не были бы оптимизированы связи объекта с классом и связь наследования у классов, то в общем счете было бы четыре вида связи. Вдобавок к описанным были бы связи вида «являться» и «наследует».

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

    Статья:
    состоит использует
    заголовок (1);
    ­дата создания (1);
    ­текст (1).
    категория (1);
    ­автор (1);
    ­комментарий (Много);
    ­файл (Много);
    ­фотография (Много);

    Атрибут «is_mandat» тоже используется связью класса, определяющей свойства у объектов, и является признаком, что свойство обязательно должно существовать у объекта, если значение атрибута не равно 0 (логическое значение).

    Атрибуты «primary» и «secondary» осуществляют уже непосредственную связь между сущностями по их идентификаторам – являются внешними ключами для связывания таблиц объектов. Само связывание выполняется логикой модуля Data.

    Таблицы «id», «class» и «link»
    В итоге у нас имеется три основных класса – три сущности, на основе которых будет полностью построена модель содержимого сайта. На диаграмме отображены три созданные сущности. Пришлось даже сочинять способ их отображения одновременно в виде классов и объектов. Простой объект от класса на диаграмме будет отличаться отсутствием прямоугольника с определением атрибутов.

    Диаграмма базовых классов
    Логика модуля данных Data различает только эти три типа сущностей и предоставляет базовые действия: создание новых сущностей, их загрузку из БД, а также изменение и удаление. Каждый объект может иметь атрибуты и свойства в зависимости от своего класса. Классы наделяются возможностью определять свойства и атрибуты для объектов и возможностью наследоваться. Связи реализуют непосредственные ссылочные связи между объектами в программном смысле.

    Что дальше


    Впереди ещё как минимум две части на тему «модель данных». В следующей статье речь пойдет о самом модуле данных Data и будет продемонстрирован процесс создания содержимого сайта с помощью него.

    Продолжение: Модель данных. Часть 2
    Сайт проекта: boolive.ru Исходники в свободном доступе.
    Поделиться публикацией

    Комментарии 102

      +3
      Сайт проекта: boolive.ru Исходники в свободном доступе.
      Вот. Наконец-то появилось то, что каждый может пощупать. Давно бы так.
        0
        В дауне сайтик. Ждать прийдется, пока оживет :)
          0
          Оживили.
        0
        а как в метаданных описываются связи? или это будет позже?
          0
          Позже будет пример, как вызовами методов модлуя Data будут созданы новые классы данных, определны свойства, созданы объекты. В принципе, можно поковырять исходники, если не терпится
            +1
            не, мы подождём :-)
          +3
          интересно было бы пощупать проект с точки зрения производительности…
            0
            не стоит пока;)
              +1
              Да и не позиционируется проект как суперпроизводительный, у него другие задачи.
              0
              Интересно: а не Вы ли сейчас boolive.ru abшкой щупаете?
                0
                кто-то щупает блин точно(
              +5
              спрашивается — нафига все это хранить в БД? конструктить структуры надо в конфигах, и выхлопом генерировать оптимизированную схему (в SQL)
                0
                чтобы CMS была юзобильной для пользователя в первую очередь, а программистом уже во вторую
                  0
                  как раз-таки пользователям все равно, какая схема у БД.

                  Вы лучше расскажите, как будете накатывать мигрейшены — да и вообще любые изменения в структуре вашей базы (имена таблиц, колонок, их типы и т.лд.) или в именовании классов ;)
                    0
                    Изменять таблицы, то есть изменять уже существующие классы данных не стоит, это как в программе, если изменить класс, то получишь геморроя, вообще лучше сначала подумать прежде чем изменять.
                    Вместо создания мега системы для поддержки изменяемости классов, лучше просто это запретить делать и это будет даже естественно, так как в реальности класс зависим от объектов, группируя объекты (машины, деревья, животные…) с одинаковыми свойствами мы создаем класс, мы не можем изменить класс и тем самым изменить реальные объекты.
                    Конечно, возможность изменить имя класса вроде бы нужна, но её можно заменить созданием нового класса без риска на возникновение всяких непредвиденных ситуаций.
                      0
                      0_o вот это вы костыль придумали. Чтобы изменить имя класса — создать новый… это просто гениально :)
                        0
                        классы не нужно изменять каждый день
                          0
                          вообще, изменять имя класса и определния атрибутов ещё можно, а вот определние свойств или изменение наследовния уже влечет за собой серьзные структурные измения…
                            0
                            Для этого есть композиция. Советую в ГОФ глянуть ;)
                +5
                Мне кажется что за эту гибкость придется платить очень большим оверхедом.
                  0
                  А что такое «оверхед»? Нагрузка серва?
                    0
                    возможно, не спорю)) все ради гибкости и скорее это даже эксперементальный проект… думаю, когда полностью всё расскажу и раставлю по полочкам, эти идеи можно будет примить в других проектах, а возможно в будущем появятся механихмы специально оптимизированные под предложенное)) например те же ОСУБД или что-то другое оригинально. Главное почувствовать гибкость…
                      0
                      Мне кажется что тебе стоило бы опробовать эти идеи сразу на ООПшной СУБД. Я думаю что за ними будущее, и было бы хорошо, если б кто-то готовился к нему.
                        0
                        существующие ОСУБД маразматичны, и для веб-проектов «для всех» их применение означает потерю огромной массы пользователей… Создавать же самому ОСУБД как-то затратно
                          0
                          не задумывались, почему появились всякие ORM вместо использования Объектных баз данных??
                            +1
                            Потому что объектные базы ориентированы на большие проекты, например обслуживание телекоммуникационной сети, а для сайта — это чрезвычайно много. С этой работой справляются и реляционные БД.
                            Оружие нужно выбирать под жертву, а другими словами — из пушки по воробьям палить толку мало будет.

                            Чем эксперимент окончиться интересно, ибо проблема как хранить классы в реляционной БД достаточно непростая.

                            Помните, отрицательный результат — тоже результат. Желаю успеха.
                    +5
                    пахнет идеологическим фанатизмом) что всегда чревато сказывается на производительности)
                      0
                      а чего такого сложного то?? все идеально))) просто и гибко и главное работает. А загрузка объектов из БД легко поддается кэшированию… да ещё какой гибкий механизм поиска реализован, ой ой ой)) в третьей части о нем.
                        –1
                        На словах все идеально. В реальном мире идеальных вещей нет.
                          +1
                          смотря как и на что смотреть, вопрос философский))
                          0
                          главное работает где?) на чем? на каких нагрузках?)) много чего легко поддается кешированию, а как у вас комментарии представлены? это тоже объекты которые кэшируются? и грузятся из кэша?))) ну ну) ничего простого тут не вижу вы нагородили излишних огородов, для всего что вы описали достаточно было две таблицы завести таблицу NODES и таблицу NODES_RELATIONS которая реализует связи много к много и этого бы вам хватило для создания модели графа и соответсвенно для реализации любых связей ну и еще вспомогательные таблицы тип таблица TYPES (типы — типы связей типы нод и т.д. прочая метаинформация) и таблицы с атрибутами нод все) выже нагородили ненужных сущностей
                            0
                            Если бы хватило, я бы их и применил.
                              0
                              смешно правда, вы сами предлагаете 3 сущности)) NODES, NODES_RELATIONS и TYPES
                          0
                          Зачем создавать отдельные таблицы для описания классов, если объекты каждого класса будут хранится в своих таблицах, и по этому уже будет понятно какого класса это объект и какие у него поля. Или вы хотите хранить объекты как-то по-другому?
                            0
                            все дело в предоставляемой гибкости. У класса, как и обычного объекта могут быть свойства — это подобие статических свойств в программировании. Например, на сайте будет форма для создания новости. Само слово «новость», описание что зачем и куда.., человеко-понятные заголовки для полей — все это свойства класса. В следующей части будет понятней.
                              0
                              также классы могут применяться для обобщения, например установка прав на «новости» — будет связь классом новостей… — это большая тема
                                0
                                к тому же нужно ещё хранить инфо о наследовании классов
                                +4
                                CMS с метаданными — это жесть в плане производительности…
                                  +4
                                  я понял секрет. чтобы получить плюс коменту — нужно упомянуть сакральную «производительность».

                                  пробуем:

                                  Производительность?!
                                    0
                                    «Производительность» — перестает быть мифом когда хостер начинает пинать вас за то что грузите сервер по самое небалуйся…
                                      +1
                                      нагруженные проекты на шаред-хостинге?
                                        0
                                        А почему нет?
                                        Одно дело — легкая cms на инклудах, которая и на шареде ведет себя быстро, а другое — монстр, который на коло нужно вешать, как минимум :)

                                        ЗЫ: Рано говорить о производительности системы, которой еще нет :)
                                  0
                                  интересно. ждем следующую часть. надеюсь в след. части будет больше конкретных примеров
                                    0
                                    будут одни примеры
                                    +1
                                    boolive, а в чём рисовалась эта красота? :)
                                      0
                                      Поддерживаю. Вообще, все схемы на сайте в чём рисовались?
                                        +1
                                        в векторном редакторе, не нашел редактора диаграмм для своих фантазий ;))
                                        +3
                                        А потом CMS будет тормозить как не понятно что. Тут даже особо кеширование не поможет. Представьте себе, как это все прекрасно ляжет под нагрузками…

                                        Создать идеальную CMS — это утопия.
                                          0
                                          Слушайте, речь не об идиальной CMS. Это больше эксперименты в поисках достижения гибкости cms о которой все мечтают и от чегго каждый первый хотябы думал о создании своей cms
                                            0
                                            Как CMS не растягивай и как её не согни — это все равно коробка, а коробки нужно использовать по назначению — для упаковки типовых продуктов, под которые они собсно и создавались. Нужен гибкий инструмент — используй фреймворк, благо достойных много — Symfony, Django, Ruby, .Net… А идея загнать классы в таблицы не кажется интересной.
                                              0
                                              Вы думаете о праграмистах. Я делаю систему, опираясь на желаниях пользователей — иметь гибкие возможности в управлении содержимым сайта — создать новый материал, что-то изменть, добавить фоток, позволить коментировать то-то — это так минимум на словах. Фреймворки мало чем помогут в создании подобных возможностей.
                                                +1
                                                О пользователях я думаю. В первую очеред они хотят быстро управлять содержимым, и чтобы думать поменьше, и чтобы мышка сама в нужном напрвлении двигалась. А вы их заставляете конструировать структуры, описывать объекты, ещё и в идеологию нужно предварительно вникнуть. Это им меньше всего надо, на мой взгляд. Сорее всего они списхнут все на обслугу — коим часто выступает програмист средней руки, думаю в нормальном виде с классами куда приятнее работать, и эффект на порядок выше.
                                                  0
                                                  Ну это ещё смотря как реализовать. Предложенная модель не определяет как будет выглядеть gui интерфейс создания этих самых классов. А сделать можно очень просто, программерские понятия класса и объекта заменить на обыденные, например тип материала и сам материал… Посмотрите, даже связи между сущностями упрощены и предложены два варианта «использовать» и «состоять» — как раз понятно и обыденно)) И вообще объектный подход как раз естественен для человека.
                                                    0
                                                    Думаю, что у CMS есть 2 типа пользователей:

                                                    — Интеграторы (те, кто делает сайты на основе CMS)
                                                    — Администраторы сайтов ( кто пользуется плодами интеграторов )

                                                    Для первых и предназначена гибкость, а вот вторым нужна простота и производительность…
                                                    0
                                                    В UMI-CMS несколько схожий по идеологии конструктор типов данных, в 90% случаев работет с ним только программист устанавливающий проект на систему. Вобще любые манипуляциии со структурой данных в большинстве случаев больно сказываются на работе сайта, т.к. переплетаются с шаблонами и прочим подобным, без представлений о том как построен проект туда лезть не следует, это скорее зона разработчика чем пользователя.
                                                      0
                                                      создать объект (статью, комментарий...) ещё проще, точнее сделать для его создания удобный веб интерфейс
                                                        0
                                                        «точнее сделать для его создания удобный веб интерфейс » — золотые слова, юзеру нравиться понимать что он создает, минимум абстракций — оставьте их программисту

                                                +1
                                                да что вы все к нагрузкам/производительности-то прикапываетесь?
                                                тема жутко академическая. человек рассказывает свою практику. человек рассказывает свои идеи.
                                                эти идеи, возможно, простимулируют читателей на собственные подвиги, на новые реализации старого, итд итп.
                                                он никого не заставляет делать так, как пишет. и он не пишет гугл — под 10b хитов в день этому коду никогда не бывать.
                                                  0
                                                  Вань, ты хочешь сказать, что CMS — это суто академическая тема?:-))

                                                  Вопросов бы не было, если бы человек написал про модель данных без привязки к «архитектуре CMS».
                                                +1
                                                А чего все уперлись в тормоза? Разве нет рынка сайтов, которым далеко до высокой и средней нагрузки? Да таких, IMHO, большинство, и в них подобный подход как раз и можно будет употребить.
                                                  +2
                                                  Поздравляю, вы виртуозно разложили грабли в тёмном амбаре. Осталось только включить музыку и начать танцевать.

                                                  Про мелкие ляпы типа "«использовать» (агрегация, ассоциация)" даже писать не хочется :)

                                                    0
                                                    Уверяю вас, когда я расскажу о теории на основе которой все построено, вы меня совсем не поймете и все забракуете, так я многое изменил во всем известной объектной модели от Г.Буча :))) и знаете это все работает
                                                      0
                                                      Будте любезны, расскажите.
                                                        0
                                                        в четвертой части статьи расскажу) будет хоть повод интерисоваться)
                                                      0
                                                      «использовать» — и это все не от балды взято, между прочим идеи и теория на основе которой все строится развивается уже год с лишним, не надейтесть, что я тупой в ооп))
                                                        0
                                                        Если вы замечательно разбираетесь в объектном проектировании, в чем я не сомневаюсь, то зачем такие сложности? Почему не использовать для достижения гибкости стандартные паттерны?

                                                        Ваши эти «состоит» и «использует» давно уже существуют в нормальных определениях фабрика, бридж, адаптер… =)
                                                      0
                                                      изобретаете велосипед, чем проще, тем лучше
                                                        0
                                                        подобный комментарий любой способен написать… даже не поспоришь
                                                          0
                                                          а вот возьмите и напишите, как проще и как лучше. м? :-)
                                                            0
                                                            Не поверите, но давно уже написал. И в ней чтобы собрать одну страницу не надо делать 15 запросов к базе данных. Гибкость штука хорошая, но надо знать меру.
                                                              0
                                                              напишите не код, а статью. код каждый горазд писать «идеальный и производительный».
                                                                –1
                                                                нет слов)) предпочитаю заниматься делом, а не бумагомарательством.
                                                                  0
                                                                  к чему вы отнесёте свой первый критичный комментарий тогда? к делу или к марательству? :-)
                                                          –2
                                                          Хоть и не совсем в тему, но все же:

                                                          Мож кто бросит линком на статейки описывающие написание модульного движка… т.е. как в распространенных cms и blogs. Чтоб с интеграцией в админку и последующей активацией… нифига найти не могу… так и приходится по старинке писать — жесткую отлаженную структуру.

                                                          Еще раз сорри за офф.топ
                                                            0
                                                            А скажите в какой программе можно нарисовать такие красивые классики? base_clasess.png :)
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                              +1
                                                              Статья интересна хотя бы тем, что показывает как можно организовать хранение классов и объектов в реляционной БД. Это как 3 способа хранения иерархических данных…
                                                              А то, что эта модель показывается на CMS, не так уж и критично. В конце-концов никто не отменял кеширования, Materialized Views, и т.п. извращений с помощью которых можно «придумать» способ заставить всю эту гибкость работать с приемлемой производительностью…
                                                              Ожидаю в следующих статьях увидеть как CMS будет строить и модифицировать (через Веб интерфейс) «нативные» SQL таблицы и индексы для хранения объектов данных. Для линков нативную таблицу я увидел, а вот как автор предполагает хранить товары в каталогах пока не вижу :)
                                                                0
                                                                Уронили такому хорошему человеку сайт своим Хабраэффектом…
                                                                  0
                                                                  мораль: не хочешь завалить сайт — не пиши о нём на хабре? :-)
                                                                  0
                                                                  Это типа реализация flexible tree или я что-то путаю?
                                                                    0
                                                                    путаете. Это спопсоб представления объектной модели в таблицах
                                                                    0
                                                                    Объясните мне скудоумному в чем главная идея, почему не использовать уже готовую реализацию ORM?
                                                                    В чем соль?
                                                                      0
                                                                      существующие ORM связаны с кодом — классы программируются, структура программируетя
                                                                      0
                                                                      Посмотрел архитектуру CMS. Есть модуль Request, спрашивается, а где же тогда Response?
                                                                        0
                                                                        Page, X и другие в зависимости от формата ответа
                                                                          +1
                                                                          Мне кажется, что Response должен быть абстрактным классом с реализацией некоторой части логики, а Page и X должны наследоваться от Response и отдавать разные ответы. Т.е. ответы в виде XML, XHTML или же, к примеру, вывод в консоль, куда не надо выводить заголовки и где по-другому форматируется тело ответа.

                                                                          У вас такая реализация, я правильно понимаю?
                                                                            0
                                                                            Я с вами согласен, можно сделать модуль Response, который как и Request по сути ничего делать не будет, только)))) но будет интерфейсом для всех других модулей формрующих результат
                                                                        0
                                                                        Автор, кстати, не нашел, как у вас будет маршрутизироваться запрос внутри приложения?
                                                                        И будет ли использован REST?
                                                                          0
                                                                          О нем не думал и не знал ;)) пока только http.
                                                                          о процессах внутри приложения ещё почти ничего не говорил… всё в свое время
                                                                            +1
                                                                            Кстати, советую все модули (в ваших терминах) разрабатывать отдельно.
                                                                            Относится к ним как к «черным ящикам». Для этого нужно понять, какие данные требуются для работы модуля, и какие данные должен отдать модуль (а точнее — инкапсулировать в себе).

                                                                            В общем, я это к тому, чтобы как можно сильнее уменьшать связанность модулей, тогда рефакторить будеть сказочно удобно.
                                                                              0
                                                                              те есть вместо событий придумать общий интерфес работы с модулями?
                                                                                0
                                                                                Bonch прав кстати и я тоже так считаю. Модуль должен быть вообще как отдельная программа. И желательно «придумать» не только общий интерфейс, но и единый контроллер.
                                                                            0
                                                                            Да, многие CMS так устроены, тот же eZ Publish (www.ez.no)
                                                                              0
                                                                              Вот видимо так и рождается Друпал с 400 запросами на страницу… автору конечно удачи, и советую ознгакомиться, хотя бы в обьщих чертах с Ruby On Rails — вещь (вроде как) тормозная, и для реального использования не очень пригодная, но идей там очень много интересных!
                                                                                0
                                                                                в друпале cck и view сбоку приписались
                                                                                0
                                                                                Как эволюция cms и технологий, советую унифицировать и перейти на единый контроллер.
                                                                                Кстати заметил и explay пошел по этому пути.
                                                                                Чем проще система — тем она быстрее и стабильнее.
                                                                                Посмотрите вокруг. Шейдеры видеокарт унифицировали. Ядро corei7 унифицированная эволюция ядра core.
                                                                                Не зря все пытаются унифицировать и упростить.
                                                                                Я думаю Вам надо все таки выбрать и определить идеологию. А потом и архитектуру.
                                                                                  0
                                                                                  > выбрать и определить идеологию
                                                                                  я о ней рассказываю, но не могу все сразу изложить и в принципе не пытаюсь одной статьей все сразу рассказть))
                                                                                    0
                                                                                    Идеология должна быть в тезисах — этого достаточно, а здесь Война и мир ;)
                                                                                    Это уже не идеология, а демагогия ;)
                                                                                    0
                                                                                    Выходит, я унифицирую работу с данными. Не придется теперь в каждом новом модуле заботиться о таблицах в БД, да и модули теперь другим заняты
                                                                                      0
                                                                                      Вы пробовали писать под MVC системы?
                                                                                      Советую попробовать. Особенно попытаться поюзать ROR, прикоснуться, так сказать, к передовым вещам.

                                                                                      Правильно maxic говорит — унификация должна быть в сторону контроллера.

                                                                                      Заботиться о таблицах БД? Ну да, не надо, если есть хороший ORM (под php пока не встречал) и кодогенераторы + миграции.

                                                                                      В общем, велкам в личку:)
                                                                                    0
                                                                                    Чем-то похоже на UMI CMS.

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