parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Пока формируется список желающих ...

kirill v.2 05.09.2003 11:49

Если кто уже думал над архитекутрой [движка|CMS|прочие_синонимы] (особенно sly!).
У меня легкий паралич от анализа. Очевидно, что при проектировании нужно учитывать изменения реализаций. Струткура сайта и данные о параметрах страницы могут жить в таблице базы, а может непосредственно в xml-файле. Клиенту это должно быть глубоко до фени. Старая версия моего движка имеет реализации для абстракции (по одной для каждого случая). Очевидно, что такой подход с иерархией наследования порочен (рост количества частных случаев напоминает геометрическую прогрессию, и иерархия классов выходит из под контроля). Особенно если еще требуются разные методы работы с юзером etc. Понятно, что нужно применять шаблон проектирования, упорядочивающий классы. Клиент в любом случае работает с абстракцией страницы, которая сама знает, откуда и в каком виде брать структуру сайта, параметры страницы для получения контента, опознать юзера и проверить права доступа etc. Изменения могут вноситься как на уровне абстракции (вариации для клиентов типа браузера, браузера, понимающего XSLT, или вообще отдельного приложения для случая установки CMS на клиенте, в моем случае - HTA), так и на уровне реализаций - источник структуры сайта, контента запрошенной страницы, опознание и авторизация юзера (создание его объекта) etc.
Вопрос. Первым приходит в голову использовать шаблон Bridge. Тогда нюансы реализации отвязываются от изменений абстракции и количество классов растет абсолютно линейно. Нет ли лучшего подхода ? Например Abstract Factory ?