?

Log in

No account? Create an account
Нэцкэ

Компоненты Symfony

Развитие Фреймворка Simfony само по себе интересный и поучительный опыт. Это очень значимый проект.

Ведь почему у него был такой успех? Потому, что руководство по Symfony было в тоже время крайне понятной и лаконичной книжкой про то, как надо делать фреймворки и большие проекты вообще. Именно там наглядно было показано что такое MVC, ORM, Тесты, развертывание приложения, scaffolding. Можно было прочитать и многое для себя уяснить. Почувствовать паттерны в жизни.

Проект типа быстрый старт тоже был крайне забавный, и был изложен в виде 24-дневного марафона с инструкцией вида "сделай сам", проходился почти, как квест.

Вот что дает дуэт хорошего программиста и очень талантливого технического писателя.

Выход Симфони сразу сделал огромную армию CMS устаревшими. Ведь как бы хороша не была CMS, сделанная без нормальной архитектуры развивать ее дальше становилось все труднее и труднее. Понятно, что чтобы выжить нынешние системы должны будут переползти на новую архитектуру.

Теперь проект Симфони делает следующий шаг. Они разделяют фреймворк на компоненты, которые можно использовать независимо. И это очень важный момент. Конечно, можно сказать, "да это очевидно, что так надо делать". Однако Вы попробуйте из монолитного фреймворка что-то вынуть, чтобы можно было использовать независимо. Так делали в ezSystems, так делали и в LIMB. И то, что так делают в Symfony говорит о том, что они очень правильно развиваются и отличный ОО код позволяет им выделять компоненты.

Последний компонент касается крайне важного паттерна проектирования — Dependency Injection. Честно говоря, я много про него читал, но на практике не очень видел как применить, и теория была для меня довольно абстрактной. Симфонисты и здесь выдержали фирменный стиль. К компоненту приложена книжка, которая начинается с главы "что такое Dependency Injection"? И шаг за шагом некоторый учебный класс рефакторится в элегантное решение. Чтобы показать, что компонент может использоваться не только с Симфони, в качестве примеров используются и классы из Zend-фреймворка. Жалко только, что книжку нельзя скачать.

Вот еще один пример использования этого компонента с Zend-фреймворком.

Comments

Если короче, то компоненты той же симфони врядли можно будет использовать "независимо" от остального функционала. Разве что они отвязывают свои компоненты от своих же компонент, но не отвязывают человека от симфони. А чтобы использовать их "независимые" компоненты, придется либо брать совместимый фреймворк (под который они подгоняли компоненты), либо свои затачивать под них. В иных случаях будут работать только простейшие классы с парой методов set/get.

Вообще я не люблю Push метод передачи объектов. У меня преобладает Pull по типу
public function __construct(){
$this->db=CMS()->DB()->getDB();
}

Таким образом я могу разом менять функционал везде. Общее изменение с push методом требует фабрики для каждого типа объекта. В этом есть плюс, если иногда надо использовать классы отдельно от функционала, типа тестирования. Но я не использую тесты и потому обхожусь без фабрик. Каждый класс делает то, что ему хочется и спокойно выкидывается, потому что нигде отдельных фабрико-конструкторов нету.
Я тут поразмышлял немнного и ответил постингом:
http://fantaseour.livejournal.com/123090.html