WatchRooster писал(а):
Кстати, возможно, имеет ещё смысл минимизировать зависимости между различными компонентами системы, либо сделать их опциональными.
Согласен, именно в этом духе я работаю над новой веткой WSCore 2.0. Минимизировать зависимости между компонентами. Ядро будет либо минимальным, либо его вообще как такового не будет, а будет просто набор взаимозаменяемых и/или опциональных компонентов.
Из личной переписки:
Цитата:
Я планирую дальше развивать в WSCore компонетный подход, я планирую переходить
от "монолитного" ядра в пользу, так сказать "микроядра" или даже вообще
на "безядерность". Возможно WSCore просто превратиться в набор компонент,
которые можно повторно использовать.
Так, например, обработчик форм скорее всего будет просто отдельным компонентом
(классом). Я даже допускаю, что может быть реализованно несколько разных
обрабочиков форм. Разные обработчики форм могут использоваться в разных
проектах, и даже в одном проекте может использоваться несколько обработчиков
форм (скорее всего так будет в PMS, т.к. разом перевести всё на новый
обработчик почти нереально).
Шаблонизатор - тоже будет отдельным компонентом (один или скорее всего два
класса). И тут тоже, думаю, что в приципе может быть несколько реализаций. А
в каждом конкретном проекте использовать то, что больше подходит.
Каждый такой компонент будет небольшим и решать свою маленькую задачу. Чтобы
упростить внедрение того или иного компонента в проект, желательно
минимизировать число зависимостей, чтобы каждый компонент работал по
возможности более автономно. Если где-то от зависимостей избавиться не
получается, то можно использовать "интерфейсы".
Интерфейс в более широком понимании, чем абстрактный класс. Интерфейс это
набор соглашений, протокол, если хочешь, по использованию какого-либо модуля
или компонента. Так например, если модуль А требует интерфейс Interface1, то
он будет работать с любым модулем Б, реализующем Interface1. Модуль Б может
реализовать несколько интерфейсов и тем самым обеспечивать поддержку
множеству других модулей.
Пример, новая версия idx использует интерфейс IWSCoreDB2. Если класс драйвера
БД реализует такой интерфейс, то idx может использоваться с таким драйвером
БД. Интерфейс не обязан обявлять все возможности драйвера ядра, и IWSCoreDB2
например не регламентирует процедуры создания/удаления таблиц, только
процедуры выборки и обновления данных.
Цитата:
на мой взгляд, стоит ещё подумать о возможности опционального использования драйвера БД. В частности, можно застаить модуль сеансов использовать стандартные сессии PHP в случае, если ему не предоставлен доступ к БД и так далее. Это даст возможность использовать данный framework для любых веб-приложений, в том числе не работающих с БД (хотя, конечно, вопрос об актуальности таких веб-приложений открыт, но это уже тема для отдельного разговора).
Вместо этого я предлагаю использовать интерфейсы (см. выше цитату). Так, можно определить интерфейс ISessionManager, который определяет набор методов для работы с сессиями, но сама реализация зависит от "провайдера" (класса реализующего интерфейс), который уже либо хранит данные в БД, файлах, использует PHP-сессии или как-то ещё. Вместо того, чтобы делать один монстроподобный класс, который умеет хранить сесии и в БД и в файлах и использовать PHP-сессии, мы пишем три маленьких класса реализующие один интефейс. Один класс хранит в БД, другой в файлах, третий использует PHP-сессии. Каждый класс маленький и лекго поддается разработке и сопровождению. Если нужно реализовать поддержку нескольких механизмов обработки сессий, то мы просто в ключаем в проект несколько классов, а выбор того или иного механизма выбирается выбором класса на этапе конструирования менеджера сессий.
Вход
Регистрация
FAQ
Поиск
