Я бы не был так категоричен, что WolfHunter должен принимать в метод hunt любое животное. Если он охотится только на волков - куда безопаснее принимать в этот метод только волка. А остальное уже проблемы программиста...
galliard, Сори, невнимательно прочитал. Тогда с этим проблемы, т.к. контейрен симфони компилируется единожды при старте приложения. Тогда я бы использовал фабрику в конфигурации DI (проще поддерживать).
semki096, Ну да, только в первом варианте вы должны подсказать контейнеру как создать объект UserController ( если конструктор UserController не пустой). И так для каждого контроллера. А второй вариант для ленивых - отдаем сразу контейнер и там уже получим что захотим.
semki096, Передавать контейнер в слой контроллеров и уж тем более бизнес логики не правильно. Но так делают даже в крупных реальных проектах, которые приносят миллионы. Все зависит от ваших навыков. Если вы сейчас обучаетесь - продолжайте получать результат(но с оглядкой на рекомендации). С другой стороны, если вы столкнетесь с проблемами, возникшими в результате внедрения контейнера в контроллер - этот опыт тоже пойдет вам в плюс. Только сомневаюсь, что в домашних проектах вы с этим столкнетесь. Ведь все эти ограничения возникли для упрощения разработки и поддержки проектов одновременно несколькими десятками людей несколько лет.
semki096, Вообще в контроллер не нужно контейнер передавать. В идеале ваше приложение вообще не должно зависеть от контейнера. https://github.com/PHP-DI/Slim-Bridge - вот хороший пример. Контейнер создает контроллер на основе рефлексии. А код вашего приложения не использует контейнер и вообще о нем не знает.
Это просто пример. Разумеется в приложениях с хоть какой-то логикой никто не пишет callback'и в файле роутинга. Для быстрого теста вариант приемлемый.
На самом деле Laravel/Lumen под капотом используют тот же fastroute, что и slim.
Пётр Грибанов, На рабочем проекте Doctrine и не пахнет, только Active Record.
О Doctrine спрашиваю т.к. хочу разобраться и в контектсе Doctrine и в контексте Active Record.
Плюс в тех проектах, где работал с Doctrine, модель тоже была анемичной
Но как в контексте Doctrine реализовать доменную модель User с методами buyService? Получается будет доменная сущность User, она будет лежать в домене. А сущность бд User будет лежать где-то еще?
Когда только начинал учиться нам по физике сказали «приходите и переписывайте прошедшую лекцию на чистовую в другую тетрадь». Времени это отнимало много, но зато таким образом переписанные лекции я понимал сходу, т.к. описывал подробнее по памяти те места, которые не успел записать в аудитории (в первую неделю они прекрасно воспроизводятся по памяти).
Считаю, это хороший вариант для «сложных» лекций, а простые можно дополнить и прямо в конспект (можно даже место оставлять).
у вас же в примере задано
2013-01-01 — 2013-01-20
2013-01-21 — 2013-02-20
именно так и отработает.
если вам надо что-то вроде
2013-01-01 — 2013-01-20
2013-01-21 — 2013-01-31
2013-02-01 — 2013-02-20
2013-02-21 — 2013-02-31
то можно увеличивать кратность: 2*MONTH(archive_date)+IF( DAY(archive_date<=20),0,1)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Уточнил, что у меня версия 5.6 и получаю ошибку синтаксиса
https://www.db-fiddle.com/f/tgXM33yJEr4fS1dneTfh4K/0