Как сделать фреймворк с архитектурой как в Yii?

Question

[raycheel]

Здравствуйте. Объясните, пожалуйста, как сделать framework, похожий на yii, интересует компонентная структура, точка доступа Yii::app(); , и Active Record.

Answer 1

[Сергей Протько]

наплюйте на принципы единой ответственности и инверсии зависимостей, влепите сингелтон и вуаля! Ах да, и не забудьте про один базовый класс аля CObject или CComponent для вообще всего что есть во фреймворке (ну или в большей части его частей).

А если серьезно, то зачем? В целях обучения? Если так, то может имеет смысл сразу почитать литературу на эту тему? Сразу больше всего откроете для себя.

Comments

[Александр Макаров]

Если всё перечисленное сделать не подумав, получился совсем плохо.

[Сергей Протько]

@SamDark, ну да, согласен. Лет 5 назад я сам занимался такой фигней как написание своего фреймворка, скорее для саморазвития, и архитектура у меня была очень схожа с той, что в yii. Потому я и использовал его после этого еще два года.

Answer 2

[Кирилл Арутюнов]

Рекомендую не зацикливаться на каком-то одном фреймворке, а просто попытаться реализовать свой MVC фреймворк. Это даст какие-то теоретические основы + практические навыки.

Comments

[raycheel]

@SOKOJI
Есть ли какие-то источники, опираясь на которые я смогу написать свой MVC&

[Сергей Протько]

@raycheel, свой MVC - врятли. Википедия разве что. Вообще MVC это такая абстрактная вещь... Лучше реализуйте пока фреймворк, позволяющий вам делать то, что собственно ему придется делать - обрабатывать запросы и возвращать ответы. Посмотрите на symfony/httpkernel, в частности на интерфейс HttpKernelInterface. Как довод к тому, что стоит его использовать в своих реализациях, можно привести возможность использовать готовые мидлвары.

А как именно идет обработка запросов - там уже можно применить и MVC, и SOA и что только угодно.

[Александр Макаров]

rmcreative.ru/blog/post/mvc-view, rmcreative.ru/blog/post/mvc-front-controller-contr...

Answer 3

[whiteleaf]

@raycheel Если Вам интересно узнать об основах построения, то наверное вот эта книга может быть интересна
Pitt C. - Pro PHP MVC

Answer 4

[Blumfontein]

Если вы задаете такие вопросы, можете даже не пробовать, ничего путного не получится.

Comments

[raycheel]

Если ничего не пробовать ничего не получиться...

[Blumfontein]

Для начала паттерны разберите. Фабрики, ServiceLocator, а еще лучше DIC. Вот когда напишите свой DIC, тогда сами на свой вопрос и ответите.

[Blumfontein]

Да, и на Yii не ориентируйтесь, архитектура там гавно. Если интересно устройство фреймов, начните с Kohana. Поймете MVC и напишите свой. Потом приложите DIC и Composer и познаете дзен.

[Сергей Протько]

@Blumfontein, тогда уж почитать цикла статей об устройстве symfony и концепции request/response. Сделать еще один фреймворк на базе HttpKernelInterface.

[Blumfontein]

Сразу symfony, да вы издеваетесь :)

[raycheel]

@Blumfontein
Я так понимаю, что под DIC вы подразумевали Dependency Injection ?
Есть ли у Вас рекомендации по источнику информации, с чего начать, где или что читать?
И почему Kohana? Видел, что его закрыли...
На счет не "good" архитектуры Yii, я тоже не совсем понял. Спасибо!

[Сергей Протько]

@raycheel, yii не очень хороший пример хороших практик в плане архитектуры приложения. Он нарушает все принципы SOLID, реализация некоторых моментов в нем уж сильно спорная (вторую версию я видел мельком, расстроился и не стал глубоко всматриваться), у него не предсказуемый цикл релизов и т.д.

По поводу Dependency Injection Container, пожалуй лучшая в мире php реализация, это PHP-DI. В частности автоконфигурирование на основе рефлексий.

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

В конфиге у вас задано, что для такого интерфейса нужно использовать такую-то реализацию, и DIC, когда у него затребуют какой-то компонент, сам создаст инстанс класса, передсат ему интансы сервисов, от которых зависит наш, и нам не нужно писать всякие new MyFooService, все за нас делает dependency injection.

Так как компоненты системы ничего не знаю о реализации, мы можем их подменять. То есть если нам вдруг понадобится заменить реализацию RendererInterface на другую (например, другой шаблонизатор), то мы просто в конфиге прописываем соответствие этого интерфейса нашей нужной реализации, и все. DIC уже сам будет инджектить то, что нам нужно.

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

Словом, слабосвязанные системы - это наше все. А yii относится к сильно-связанным, что налагает определенные ограничения и уменьшает расширяемость.

[raycheel]

@Fesor , спасибо. Очень понятно описали!

Answer 5

[raycheel]

@Fesor
Что можете порекомендовать почитать? Я хочу сделать себе маленький фреймворк, для собственных нужд, маленькие заказы и прочее. Чисто своё - приятнее же. :)

Comments

[Сергей Протько]

приятнее взять какой-нибудь silex c доктриной/пропелом/любая другая ОРМ по вкусу, и делать дела, а не страдать фигней. Писать свой фреймвор выгодно в плане обучения, но использовать его в продакшене... это было модно лет так 5-6 назад.

По поводу почитать - почитайте про ООП, про SOLID, поищите ответ на вопрос "почему декораторы лучше наследования" и т.д.

[raycheel]

Шикарно! Спасибо за инфу!