MVC не о том что надо разделять шаблоны и код, а о том что надо разделять логику представления и бизнес логику посредства введения дополнительного слоя, который будет знать как работать и с тем и с другим. И чем тоньше этот слой тем лучше.
убунта на юнити тормознее жирной восьмерки, а вот на гноме можно жить. Да и воьмерку можно весьма легко оттюнить что бы жилось нормально. Там половина лагов искуственные, связаны с анимациями и т.д. Ну и там есть нюансы - NTFS медленнее EXT4 или btrfs. Тут не в виндах дело.ц Но на SSD это не особо чувствуется.
ftugit: да они все могут работать на контроллерах, у всех есть фронтконтроллеры, часть предоставляет возможность делать мидлвэры. Но опять же меня смущает формулировка про маршрутизацию. То есть без нее как-то... никак, нет?
Kir ---: на изучение паттернов можно смело забить, но прочитать о них стоит. Просто концентрировать внимание не нужно.
А вот штуки типа SOLID или GRASP изучить стоит, так как это как раз таки базовые идеи, на которых все эти паттерны и строятся.
тут другой вопрос, для JS это все работает только на половину. Для JS есть еще функциональное программирование. Скажем большинство применяло каррирование (в основном когда делали свой кастыль вместо Function.bind), или там почти использовали монады (когда юзали промисы) и т.д.
Евгений Петров: да я тоже хорошо если половину знаю, и то если меня попросят перечислить вспомню только четверть. Но вот смотрю на список - шаблон Visitor, две секунды тупил а потом вспомнил что использовал (удобная штука когда работаешь со структурами данных), потом смотрю шаблоны поведения классов и немного туплю... почему там треть списка - GRASP, которые больше принципы чем паттерны...
Muhammad: ну идея в общем-то простая. Я обычно делаю как, у меня есть надстройка над Symfony/routing (я работаю с Symfony и там это все делается на ивентах, у вас же есть мидлвэры), которая помимо URI и метода запроса учитывает еще и версию (прописывается в настройках маршрутизации). Это позволяет более гибко задавать правила маршрутизации и не особо парится по поводу каких-то вещей.
Далее мы просто в контроллере формируем DTO из той версии что у нас есть под наше приложение, которое и знать ничего не знает о версионизации какой-то. Ну и затем мы получаем опять же из сервиса какое-то DTO и формируем ответ.
Muhammad: ну полностью дублировать контроллер при изменении версии это как-то не круто, хоть и можно. Но тогда контроллеры должны быть ооочень тонкими. Можно просто добавлять методы для каждой новой версии и как-то на мидлвэрах пробовать ресолвить. Мол....
Если мы обращаемся к API с версией 3, то смотреть, если у нас есть метод контроллера saveEntity и метод saveEntityv3, то вызывать второй. Ну мол менять то что наресолвил нам ларавель. Или по аннотациям/настройками дополнительным маршрутизации но это сложнее, зато круче.
Единственное что бы я порекомендовал - использовать controller as синтаксис, что бы у контроллеров были элиасы. Это позволит быстрее разобраться что у какого контроллера дергается.
Но вообще в целом вложенными контроллерами не слишком уж надо баловаться.
DarkLynx91: хз, мне нравится SOA, когда можно разные части приложения писать на разных языках в зависимости от требований. Но все на самом деле упирается в вопросы архитектуры ну и нужно здравый смысл подключать. Если реалтайм нужен, и если будут использоваться websocket-ы, то почему бы и да, если это позволит сэкономить время.
Саша Железовский: мое личное мнение - он не нужен. Как минимум потому что мне не нравится этот подход к проеткированию интерфейсов. Мне не нравится десктопный UI. Но в целом набросать какую-то сложную фигню с кучей непонятных кнопочек (в духе энтерпрайза) - норм.
BatteryLow: а смысл, даже если бы и был, то тогда при flush доктрина бы просто догрузила недостающее и сравнивала бы (по умолчанию она всеравно так и делает).
Вообще я думаю это более чем реально реализовать, так как информация о том что мы загрузили и что мы поменяли в принципе доступна. Просто сейчас доктрина это дело не поддерживает. Но можно запилит PR.
