Комментарии 16
Даже на там же Laravel умудряются по разному писать (стандартное разделение vs модульное). Это плохо? Не думаю. Хотите стабильности? Так идите работать с WordPress или другими популярными CMS.
Посмотрите в сторону других фреймворков, не только RoR-liked, и окажется, что довольно много фреймворков не дают какой-то определенной архитектуры, оставляя это на разработчике.
Уже несколько лет существует устойчивый тренд на использование микросервисной архитектуры, yii3 лишь следует этим трендам.
Если вы подразумеваете под архитектурой принцип, по которому файлы
раскидываются по папочкам — да, есть такая тенденция, что фреймворки
это регламентируют все меньше. Как минимум, есть 2 фундаментальных принципа —
разложить по типам (контролеры / вьюшки / исключения и пр.) или же
разложить по фичам (например, есть папка User, в которой все что связано с юзером).
Эта неопределенность действительно немного усложняет вхождение в проект,
но при четком следовании заложенным изначально принципам (которые по хорошему
нужно первый пунктом описать в документации проекта) это не большая проблема.
Под архитектурой проекта можно понимать и логическое деление на компоненты,
а также регламент их взаимодействия. Например, в каком порядке выполняются обработчики запроса или как приложение обрабатывает исключительные ситуации. Это уже завязано на поток выполнения, который контролирует сам фреймворк, и именно это отличает фреймворк от библиотеки. Эти составляющие неизменны и именно их понимание определяет умение разработчика работать с фреймворком.
Админ прав: Фреймворк не должен влиять на архитектуру. Как правило есть некоторые договорённости о структуре приложения, например: шаблоны basic и advanced в yii, которые, хоть и не кардинально, но отличаются между собой. Но этим договорённостям не обязательно строго следовать.
На самом деле на yii2 можно сделать довольно гибкую архитектуру под проект, разнести код на разные модули, сделать разные точки входа (например разные для обычного пользователя и для убер админа), разнести код приложения по доменам если следовать DDD и тд. Есть конечно и приколоченный гвоздями функционал. Например расположение контроллеров, которые всегда должны лежать в одном неймспейсе, указанном в их модуле в свойстве $controllerNamespace и содержать в названии контроллера то что отражено в роуте. Или зависимость от jQuery (который зачем то надо ставить через composer, а не npm или yarn) в стандартных виджетах. Но даже тут есть гибкость в более тонкой настройке роутера и в переписывании стандартных ассетов на нестандартные.
Мне кажется что никакой фиксированной архитектуры в случае yii2 нет, но есть предложенные от разработчиков 2 шаблона приложения, yiisoft/yii2-app-basic и yiisoft/yii2-app-advanced, и 95% проектов на yii2 следуют этим шаблонам с минимальными расхождениями, поэтому появляется ощущение "жесткой" архитектуры. И не исключено что с yii3 ситуация не повторится, так что не стоит заранее сокрушаться =) Остается только дождаться релиза
Примерно те же чувства испытал, пересев с Django на FastApi.
Первый дает какую-никакую, но структуру проекта, все лежит в одной папке, все приложения в своих директориях, и модели, роуты, представления все разложены по своим файлам. Все понятно, пиши код, да радуйся.
Во втором полная свобода действий. Что самое страшное, когда джун вроде меня старается написать, что то на FastApi с более менее нормальной архитектурой и идет читать доку, а там тоже весь код приложения располагается в одном файле становится очень грустно. Потому и приходится по крохам изучать архитектуру "чистого кода". Да это сложно, да это больно, но есть мнение, что так лучше. Так и живем.
Уже примерно два года я жду релиза Yii3. Я ждал, что это будет крутой монолит, как и вторая версия, но сильно доработанная и с новыми плюшками. Но, как оказалось, Yii3 идёт вообще по другому пути.
В этом пути нет ничего необычного - фреймворк делится на отдельные компоненты, каждый из которых выполняет свою задачу.
Фреймворк Symfony написан по таким принципам, и это не мешает ему иметь "структуру папочек" по умолчанию. Впрочем, как и не мешает программистам изобретать на нем велосипеды, в которых сразу и не разберешься.
Чтобы понять в чем проблема архитектуры Yii2 (помимо прочего, и, к слову, опыт написания юнит тестов очень поможет увидеть основные проблемы) - попробуйте, например, разобраться как в нем сделана защита от csrf-атак - там один метот из одного класса, другой метод из другого класса и так во всем. Задача одна - а делается она кусочками по разным частям фреймворка. Принцип, по которому сделана симфони, и по каким принципам делается Yii3 в том, что такой размазанности ответственности не будет. Есть задача - и за эту задачу отвечает один компонент, все.
Структура "папочек" как была по умолчанию, так и останется (пусть с изменениями) в Yii3. Не в том заморачиваетесь. Я бы обратил внимание на другое - 5 лет вы заниматься разработкой на фреймворках, и не начали осваивать авто-тесты - это серьезное упущение.
У Symfony кстати есть какое-то соглашение по структуре проекта?
там один метот из одного класса, другой метод из другого класса и так во всем
ужас какой
попробуйте, например, разобраться как в нем сделана защита от csrf-атак — там один метот из одного класса, другой метод из другого класса и так во всем.
там валидация в методе Request::validateCsrfToken()
какие еще другие классы?
Я заметил, что спустя 5 месяцев после того, как я подписался на этот канал, развития практически не было.
https://t.me/yii3chronicles - хроники работы над yii3 практически в realtime-режиме
Автор предпологает под архитектурой то, что заточено в шаблоне, что модели должны лежать в папке models, контроллеры в папке controllers и т.д. Но это не архитектура приложения, а структура расположения папок и файлов и фреймворк никак не должен ограничивать это дело.
Просто есть готовый шаблон приложения на который можно ориентироваться. Но это все подходит для самых простых проектов, где через gii нагенерили CRUD и все.
Ну вот собственно и ответ: "документация - это круто, но бывает очень редко...". Просто не привычно, как я понимаю, что Yii3 отступает от всеобщего концепта. Да, это вызовет некий дискомфорт/затраты на вхождение в проект, НО, кто сказал, что а) большинство из них не будут идти по шаблонной архитектуре и б) это не делает фреймворк "плохим" или "не правильным", это лишь делает его другим.
Yii3 будет не тем, чего я ожидал