?

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

Если интерфейсы совпадают, то все прекрасно. Жаль, что в программировании само собой так не получается. Поэтому такая совместимость - целенаправленная работа по изменению компонентов, а не просто "injection" ;)
Ты сейчас про паттерн или про компоненты Симфони?

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

Ещё хуже дела обстоят, когда другая вообще идеология в проекте. В итоге можно использовать только то, что вроде бы похоже по функционалу. И не любой компонент от фреймворка подойдет, если только он специально не затачивался под "подхождение". Похожих на аналоги и по требуемости может быть всего парочка: конфиги и логгер - это первое что приходит на ум.

Есть примеры, где один и тот же сложный класс подходит к разным фреймворкам без дополнительного программирования?
Этот паттерн в первую очередь для собственной кухни -- еще один способ рулить отношениями между классами.

Конечно не серебрянная пуля, кто бы спорил.

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

В общем, если во фреймворках будет архитектура со схожими принципами, то и обмениваться компонентами будет проще.

А то, что симфонисты предлагают, это обособленные библиотеки на фреймворк не сильно завязанные, но и это уже очень хорошо.
Да. Это хорошо для симфонистов, несколько развяжет руки, но не поможет не симфонистам :)
Конкретно вот этот компонент с DI никого к симфони не привязывает практически. Берешь и используешь, постепенно внедряя. Совершенно независимый инструмент.

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

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

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

Да, и можно ли скачать то руководство по Symphony, которое "было в тоже время крайне понятной и лаконичной книжкой про то, как надо делать фреймворки и большие проекты вообще"?
хм, а вот ссылка http://components.symfony-project.org/dependency-injection/ ведёт куда и обещано
Ошибочка у них в раутере наверное :) хы.

Книжка в онлайне и внутри в сорцах в виде маркдаун-файлов, типа захочешь -- соберешь. Наверное даже в основном симфоническом репозитории есть скрипт, который собирает.

Раньше книжку скачать было можно. Потом они ее издали.
Теперь или в онлайне, или на Амазоне, или собрать из сорцов в виде маркдаун-файлов.
О, спасибо за наводку!
А есть руководство по Симфони на русском?
В принципе да. Только она отстает от официальных версий, местами может быть не допереведена, -- коммунити :) Я хотел было полезть попереводить, но как-то обломился.

http://trac.symfony-project.org/wiki/Documentation/ru_RU
А разве в Zend Framework изначально не так было? По моему они его пытаются догнать.
Неа. Во-первых Симфони была раньше Зенда. Во-вторых Зенд, -- набор компонентов, а Симфони почти среда. Ставите и прямо пользуетесь, -- развернули новый проект, нарисовали схе данных, сгенерили классы для ORM, и шаблоны для форм и списков. Написали тесты, отрефакторлись. Залили на сервер.

Они вполне себе рядом существуют.
Спасибо за ссылку на книжку про Dependency Injection. Очень интересно и доходчиво написано.