не сильно вникая в реализацию

а нет? =)

есть какой-то эталон?

мне недавно рест апи понадобился, я решил с гитхаба взять только роутинг, остальное там по сути бизнес логика и ничего особо накручивать не нужно, middleware всякие руками легко делаются

но не везде же в либах норм mvc

посмотри klain или klein не помню как, вроде достайная либа под фундамент приложения

посмотри klain или klein не помню как, вроде достайная либа под фундамент приложения

гляну, спс

есть какой-то эталон?

в последнее время работал только с Laravel (c Yii работал лет 5 назад, ничего не помню. С Zend - лет 7 назад, помню только название). Так что сравнить не с чем.

я плотно с mcv работал только в asp.net mvc 5/6

года 3-4 назад

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

т.е.? Каких паттернов?

на которых он построен

мне кажется не в каждой книге о паттернах столько описано)

мне недавно рест апи понадобился, я решил с гитхаба взять только роутинг, остальное там по сути бизнес логика и ничего особо накручивать не нужно, middleware всякие руками легко делаются

роутинг, di, orm а потом выходит свой мини фрейм . Не легче взять готовый ?

типа фасады, сервисы?

да, все их перечислять пожалуй не буду

роутинг, di, orm а потом выходит свой мини фрейм . Не легче взять готовый ?

di..ну хз, композер, неймспейсы, достаточно, реальную необходимость в специально обученном di, я видел только в ангуляре)

роутинг, di, orm а потом выходит свой мини фрейм . Не легче взять готовый ?

орм мне показался терпимым и в пхп, хотя со временем абстракций там нарасло, но эт мелочи

но не везде же в либах норм mvc

зачем норм мвс в 2017 году ?

орм мне показался терпимым и в пхп, хотя со временем абстракций там нарасло, но эт мелочи

чем плохи абстракции ?

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

зачем норм мвс в 2017 году ?

какие есть альтернативы?

чем плохи абстракции ?

ничем

плохо то что pdo без абстракций не очень юзабелен

di..ну хз, композер, неймспейсы, достаточно, реальную необходимость в специально обученном di, я видел только в ангуляре)

хех. а на выходе получаем трудно заменяемый код. не нафиг

хех. а на выходе получаем трудно заменяемый код. не нафиг

ну дак не надо хардкодиться на классы, хардодьтесь на интерфейсы

то что DI дает слабосвязанный код, эт не потому что без него нельзя, а потому что он заставляет писать правильно) без него просто пишут не всегда правильно и поэтому отсутствует слабая связанность

но конеретно в ларавель кстати DI не навязывается, писать код минуя его можно и новички наверняка так и делают, поэтому он там для красоты

в том же ангуляр попробуй пройти мимо DI, ага

*

какие есть альтернативы?

Request/Response фрейм и все. в современном мире mvc только мешает

ну дак не надо хардкодиться на классы, хардодьтесь на интерфейсы

И как же по норм. хардкорить интерфейсы без di ? Вот захотел ты поменять орм что будешь делать ?

Request/Response фрейм и все. в современном мире mvc только мешает

почитать бы про это где-нибудь

но конеретно в ларавель кстати DI не навязывается, писать код минуя его можно и новички наверняка так и делают, поэтому он там для красоты

А вот это и плохо =(

И как же по норм. хардкорить интерфейсы без di ? Вот захотел ты поменять орм что будешь делать ?

добавлю класс в фабрику, всеж зависит от абстрактной структуры в проекте

И везде все переписывать где вызов орм ?

ну не надо же напрямую юзать класс

надо его обертку юзать

аа. будешь в обертки менять вызовы на другую орм ?

ну яж про фабрику писал выше

ну и вот эти ситуации давольно смешные "что если ты захочешь ОРМ поменять", не бывает такого, эт страшилки, которые придумали для продвижения невостребованных продуктов)

почитать бы про это где-нибудь

для начало нужно понять что такое M в фрейме. Как раз в этом вся загвоздка. Где должна располагаться логика ?

ну и вот эти ситуации давольно смешные "что если ты захочешь ОРМ поменять", не бывает такого, эт страшилки, которые придумали для продвижения невостребованных продуктов)

Хех. я даже это перешлю в другой чатик =)

Что делать если завтра мы поняли что нам нее нужна монга и нужен sql ?

оу, я полагаю ты часто менял основные вещи в проекте? Сочувствую)

требования изменились

сменить бд эт не тоже самое что изменить орм) прям не рядом)

Ну окей. нас больше не устраивает AR

мы хотим на DM перейти

что тогда делать ?

Надеюсь не нужно описывать чем плох AR

не знаю о чем ты, но я все еще настаиваю на использовании абстракций

Про di и интерфейсы

для начало нужно понять что такое M в фрейме. Как раз в этом вся загвоздка. Где должна располагаться логика ?

у меня обычно так, два вида моделей. Для представления и хранения в бд. Бизнес логика шла отдельным доменом и работала только со вторым видом модели.

Про di и интерфейсы

И как безполезненно заменить AR на DM в проекте 1 сточкой в файле

ты понимаешь зачем DI были придуманы? Ну типа чтоб в методах класса никто зависимости не создавал, а все зависимости шли через конструктор, либо какой то иной подход, но никакой зависимости внутри объекта, в чем проблема следовать этому принципу без di?

мы хотим на DM перейти

что такое DM-то?

DataMapper

о, благодарю

di это как orm, его создали чтоб не допускали ошибок при написании sql кода, точно так же di не дает шанса создать плохие зависимости, но в ларавель это для красоты, как уже сказал

ты понимаешь зачем DI были придуманы? Ну типа чтоб в методах класса никто зависимости не создавал, а все зависимости шли через конструктор, либо какой то иной подход, но никакой зависимости внутри объекта, в чем проблема следовать этому принципу без di?

Для уменьшения связанности кода . У ларки и так крутой di он сам включает di в конструкторах и сам понимает что подставлять Проблема то что без di сложно поменять реализацию скажем логику работу с бд или логгер для проекта.

так этим же контейнер занимается

я год на ларавель точно уже не писал, мб там много чего изменилось, но мне просто есть с чем сравнить. В некоторых вещах где есть DI, если ты не станешь его использовать, уже через пару часов ты сам поймешь что сделал что то не так, потому что код будет крайней степени эпичности, а в худшем случае он даже не заработает, потому что ты руками все зависимости не разрулишь, в ларавель я DI никогда не использовал сознательно, только когда какие нить сервис провайдеры пишешь, там просто инициализация и di слиты, поэтому там это не обойти, а в других местах писать без di в ларавель довольно легко и не будет никаких намеков, что ты делаешь что то не так. Точки сам расставишь)

хех. в yii2 тоже не использовал di ?

да я на нем полторы строки кода писал, я даже не помню что там в нем

ERROR: S client not available

за-то спорил со мной долго на тему yii2 когда-то =(

в пхп по серьезному di я нигде не юзал, на сколько я помню

ну то что что-то убогое, могу спорить долго) это же субьективное мнение

там такой мерзкий синтаксис миграций был, а я их так много писал, страшное дело

все что я помню о yii2, это какой то минимальное количество статически возможных анализов кода, в следствии чего минимальное количество помощи от редактора, но мб тот человек, с кем я вел проект, просто в каком то не том стиле делал проект, но во всяком случае моё мнение он сложил)

у меня кстати с самого утра в браузере открыта эта вкладка (https://www.youtube.com/watch?v=bPp3lAkuMEY), весь день не могу отвлечься, чтоб посмотреть

я год на ларавель точно уже не писал, мб там много чего изменилось, но мне просто есть с чем сравнить. В некоторых вещах где есть DI, если ты не станешь его использовать, уже через пару часов ты сам поймешь что сделал что то не так, потому что код будет крайней степени эпичности, а в худшем случае он даже не заработает, потому что ты руками все зависимости не разрулишь, в ларавель я DI никогда не использовал сознательно, только когда какие нить сервис провайдеры пишешь, там просто инициализация и di слиты, поэтому там это не обойти, а в других местах писать без di в ларавель довольно легко и не будет никаких намеков, что ты делаешь что то не так. Точки сам расставишь)

Как раз я разрулю все зависимости и заменю любые реализации всего чего нужно. Ибо любой фрейм сам подставит подходящую реализацию . Это самая прелесть когда нужно что-то поменять и не нужно менять пол проекта Цель di избежать самокофигурирующихся объектов т.к. это снижает возможность их повторного использования и тестирования. DI столь же уместен как и фабрика. В случае с DI код получается !прозрачнее! обычно нет необходимости явного требования объекта создание необходимых экземпляров проходит за кулисами. К тому же проще сконфигурировать одно правило, чем добавить фабрику.

ну яж не говорил что di это плохо

хотя это определенно плохо, в силу того, что он держит в уме то, что может не пригодиться, но это мелочи до какого то момента, его плюсы несомненно хороши

я говорил лишь что в ларавель di это вот именно как фабрика, что то опциональное, а не стена которую нельзя обойти

к сожалению в ларавел это так =(

хотя это определенно плохо, в силу того, что он держит в уме то, что может не пригодиться, но это мелочи до какого то момента, его плюсы несомненно хороши

в уме или в памяти?

принципиально?

нет, просто уточнил. Есть же lazy реализации для контейнеров

мб

подскажите, как в миграции добавить значение в существующий enum? В документации написано, что никак (лол). Какой костыль посоветуете? Я даже согласен удалить и создать заново поле, но в пределах одной играции, похоже, это сделать нельзя

в sql это примерно так ALTER TABLE table_name MODIFY COLUMN column_name ENUM('foo','bar','new');

ага, ответ на второй вопрос (удалить и пересоздать) я нашёл - надо просто разделить удаление и создание в разные вызовы Schema::table()

через DB::statement("ALTER TABLE table_name MODIFY COLUMN column_name ENUM('foo','bar','new');")

в sql это примерно так ALTER TABLE table_name MODIFY COLUMN column_name ENUM('foo','bar','new');

в SQL понятно, вопрос как это прявильно сделать в laravel. Например, в постгре, лара не исполдьзует ENUM, а делает поле варчаром + проверка констрейтом

$table->enum(...)->change();

че то такое там было

или ты про это говоришь, что нельзя?

для enum не реализован change()

ну drop и create тогда

я enum не люблю, он всегда стринг, эт какой то геморой, а не тип

это потому что в php нет типа enum

да не, в пхп вообще ниче нету, а вот в самом мускуле енум не хранит же цифры

нельзя там хранить например signed byte или еще чего другого

не рациональный тип, крайней степени

мускул как-раз бинарь и хранит для енумов

1 или 2 байта используется в зависимости от количества вариантов в енуме