Здравствуйте. Объясните, пожалуйста, как сделать framework, похожий на yii, интересует компонентная структура, точка доступа Yii::app(); , и Active Record.
наплюйте на принципы единой ответственности и инверсии зависимостей, влепите сингелтон и вуаля! Ах да, и не забудьте про один базовый класс аля CObject или CComponent для вообще всего что есть во фреймворке (ну или в большей части его частей).
А если серьезно, то зачем? В целях обучения? Если так, то может имеет смысл сразу почитать литературу на эту тему? Сразу больше всего откроете для себя.
@SamDark, ну да, согласен. Лет 5 назад я сам занимался такой фигней как написание своего фреймворка, скорее для саморазвития, и архитектура у меня была очень схожа с той, что в yii. Потому я и использовал его после этого еще два года.
Рекомендую не зацикливаться на каком-то одном фреймворке, а просто попытаться реализовать свой MVC фреймворк. Это даст какие-то теоретические основы + практические навыки.
@raycheel, свой MVC - врятли. Википедия разве что. Вообще MVC это такая абстрактная вещь... Лучше реализуйте пока фреймворк, позволяющий вам делать то, что собственно ему придется делать - обрабатывать запросы и возвращать ответы. Посмотрите на symfony/httpkernel, в частности на интерфейс HttpKernelInterface. Как довод к тому, что стоит его использовать в своих реализациях, можно привести возможность использовать готовые мидлвары.
А как именно идет обработка запросов - там уже можно применить и MVC, и SOA и что только угодно.
Да, и на Yii не ориентируйтесь, архитектура там гавно. Если интересно устройство фреймов, начните с Kohana. Поймете MVC и напишите свой. Потом приложите DIC и Composer и познаете дзен.
@Blumfontein, тогда уж почитать цикла статей об устройстве symfony и концепции request/response. Сделать еще один фреймворк на базе HttpKernelInterface.
@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 относится к сильно-связанным, что налагает определенные ограничения и уменьшает расширяемость.
@Fesor
Что можете порекомендовать почитать? Я хочу сделать себе маленький фреймворк, для собственных нужд, маленькие заказы и прочее. Чисто своё - приятнее же. :)
приятнее взять какой-нибудь silex c доктриной/пропелом/любая другая ОРМ по вкусу, и делать дела, а не страдать фигней. Писать свой фреймвор выгодно в плане обучения, но использовать его в продакшене... это было модно лет так 5-6 назад.
По поводу почитать - почитайте про ООП, про SOLID, поищите ответ на вопрос "почему декораторы лучше наследования" и т.д.
Средний
