I<
В эпоху композера, понятие фреймворк не много размылось.
Size: a a a
2020 November 11
I<
Можно формально не использовать никакой фреймворк, но при этом иметь тонну пакетов в vendor.
I<
К слову, хотя компоненты симфони можно использовать по отдельности они все равно оптимизированные для совместной работы.
I<
Каркас почти целиком ушёл в либы. Можно за вечер на коленке собрать свой собственный "фрейморк".
IM
Понял, спасибо!
AN
Фреймверк требует от тебя соблюдение какой то иерархии в проекте. Структура папок, единый подход к конфигурации, и т.п. Все остальное можно сказать библиотеки.
ДЩ
фреймворки уходят в либы для удобства разработки этого фреймворка, а не для того чтобы люди брали компоненты отдельно и юзали, с полпинка мало что взлетит, плавали знаем
А
фреймворки уходят в либы для удобства разработки этого фреймворка, а не для того чтобы люди брали компоненты отдельно и юзали, с полпинка мало что взлетит, плавали знаем
Проблема кривых рук плавца.
ДЩ
Проблема кривых рук плавца.
да не скажи, вот тебе пример illuminate/database
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
А
да не скажи, вот тебе пример illuminate/database
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
Странно приводить в чате симфони в качестве примера ларавел. Про его проблемы все в курсе. Ну а почему не работает фасад DB, это проблемы не ларавеля, а твои. Зачем юзать фасад, если ты не в курсе, как он работаеет?
k
Добрый день, господа.
Наблюдаю за чатом и почти каждый раз вижу такие сообщения как «не используй orm для чтения», и мне как новичку очень интересно что это значит и почему не стоит этого делать.
Наблюдаю за чатом и почти каждый раз вижу такие сообщения как «не используй orm для чтения», и мне как новичку очень интересно что это значит и почему не стоит этого делать.
Чтобы понимать почему ОРМ для чтения - часто неоптимальное решение, надо понимать зачем нужны (какие конкретные проблемы решают) ОРМ. Чтобы понять зачем нужны ОРМ - неплохо понимать из чего они слеплены.
Рекомендую Фаулера PoEAA, там всё есть.
Рекомендую Фаулера PoEAA, там всё есть.
DP
да не скажи, вот тебе пример illuminate/database
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
Или не юзайте ненужный фасад.
DT
да не скажи, вот тебе пример illuminate/database
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
из коробки юзайте вручную длинный неймспейс и название класса Manager, а чтобы заработал быстрый фасад DB:: это надо погуглить (в доке тишина) и найти решение которое внезапно требует еще и заюзать целый DI контейнер причем не абы какой а их же, а если у тебя уже допустим есть PHP-DI то будет у тебя теперь два контейнера
Юзаю отдельно много частей symfony/* проблем не наблюдаю. ЧЯДНТ?
DT
Чтобы понимать почему ОРМ для чтения - часто неоптимальное решение, надо понимать зачем нужны (какие конкретные проблемы решают) ОРМ. Чтобы понять зачем нужны ОРМ - неплохо понимать из чего они слеплены.
Рекомендую Фаулера PoEAA, там всё есть.
Рекомендую Фаулера PoEAA, там всё есть.
Сразу с Кнута заходи, а то чё он, не программезд что-ли
DT
Вот Кнута осилишь, тогда и приходи со своими вопросами по поводу ОРМ😃
k
Сразу с Кнута заходи, а то чё он, не программезд что-ли
просто имхо это оптимальный вариант найти ответ на вопрос "почему не стоит этого делать"
Ну можно отдельно погуглить или самому в какую-нибудь доктрину залезть. Но это всё сложнее. А у Фаулера всё собрано вместе, красивенько, удобненько.
Ну можно отдельно погуглить или самому в какую-нибудь доктрину залезть. Но это всё сложнее. А у Фаулера всё собрано вместе, красивенько, удобненько.
ДЩ
Юзаю отдельно много частей symfony/* проблем не наблюдаю. ЧЯДНТ?
я хотел сказать что даже юзая отдельный компонент он легко может притащить в довесок еще компонентов и так случится что ты уже юзаешь какую-то либу подобную но не симфони и вот у тебя уже два пакета делающих одно и тоже
это как юзать в проекте PHPMailer а потом притащить Jobby а он притащит SwiftMailer, а какой-нибудь компонент симфони притащит свой symfony/mailer
или юзать FlySystem от php-лиги а какой-то компонент симфони принесет тебе symfony/filesystem
это как юзать в проекте PHPMailer а потом притащить Jobby а он притащит SwiftMailer, а какой-нибудь компонент симфони притащит свой symfony/mailer
или юзать FlySystem от php-лиги а какой-то компонент симфони принесет тебе symfony/filesystem
DT
просто имхо это оптимальный вариант найти ответ на вопрос "почему не стоит этого делать"
Ну можно отдельно погуглить или самому в какую-нибудь доктрину залезть. Но это всё сложнее. А у Фаулера всё собрано вместе, красивенько, удобненько.
Ну можно отдельно погуглить или самому в какую-нибудь доктрину залезть. Но это всё сложнее. А у Фаулера всё собрано вместе, красивенько, удобненько.
ну человеку, вопрошающему почему ОРМ для чтения плохо - советовать PoAEE? Это прям тяжелая артиллерия) Больше похоже на посылание нахер))