Я ищу уточнения о том, следует ли вводить код в контроллер, сущность или делать услугу.
У меня есть «карточные» и «карточные» объекты (где многие из них встроены в первую, MongoDB), представляемые обычными классами / объектами PHP. Они содержат атрибуты, например «id», «postal_address».
У меня есть метод, который создает PDF-файл карты. В настоящее время у меня есть внутри объекта «Карта», поэтому я могу вызвать Controller:
$card->makePDF() Это кажется мне чистым и OO, но я подозреваю, что ошибаюсь.
Если я поставил всю логику в контроллере, которая будет длинной и громоздкой, и я не уверен, что контроллер – это место для методов, которые действуют на мои объекты. Для чего нужны сервисы?
Попробовать и обобщить: должен ли объект знать все обычные вещи, которые он мог бы сделать «для себя», и иметь их внутри как функции-члены, или же методы в другом месте передаются объекту, на который нужно действовать. Если да, то где должны поддерживаться эти методы?
Я почти уверен, что это не «репозиторий», потому что это просто помогает восстановить / сохранить объекты.
Благодаря!
Генерация PDF должна быть услугой, а не методом на объекте.
В общем, и в Symfony2, особенно, модели следует просто использовать для хранения данных. Контроллеры используются для манипулирования отношениями между моделями, а представления используются для выражения данных в форме для человека или компьютера. Услуги предназначены для вещей, которые действительно не вписываются ни в одно из вышеперечисленных – вещи, которые не имеют отношения к состоянию вашего веб-приложения.
Хорошим примером является отправка писем. Письма содержат данные (модель). Пользователи отправили электронные письма (контроллер). Письма выглядят определенным образом (вид). Тем не менее, действие фактической отправки электронных писем не зависит от состояния веб-приложения (все службы знают, что его попросили отправить это письмо этим людям). Таким образом, имеет смысл, что существует независимая служба, которая просто обрабатывает отправку писем.
Точно так же акт создания PDF-файлов не зависит от состояния веб-приложения. Генератору PDF не нужно знать о том, что происходит в вашем приложении, он просто знает, что его попросили сделать PDF.
Symfony2 не является структурой MVC (как говорит сам Фабьен) именно потому, что он дает все V (ветви) и C (контроллеры), но НЕ дает часть M. M-часть является «свободной», которая будет построена по вашему желанию.
Существует большая конфуция, люди «думают», что «Учение есть модель». Но это неправда. То, что мы делаем, – это два каталога в Bundle, один из которых называется «Документ» для классов Doctrine-ODM и один под названием «Модель», где находится «бизнес-логика».
Лично я вижу, что $ card-> makePDF () имеет смысл …
Но $ card должна быть «модельной картой», которая наследует или имеет базовый объект «карта данных», который является классом доктрины.
Вы можете играть с наследованием или с интерфейсами, с создателями или с тем, что вы хотите связать с «модель-картой» с «картой данных», но ключ заключается в том, что «доктрина не является БИЗНЕС-моделью» это просто уровень сопротивления и ваша модель являются «обычными классами», которые вы можете создавать, чтобы обернуть ваши данные внутри и заставить контроллеры потреблять модель, а не данные.
Если вы будете следовать принципам SOLID, вы попадете в SRP, который заявит, что ваш класс должен иметь одну ответственность.
Я думаю, что очевидно, что создание одного PDF-файла является чем-то большим, чем моделирование данных и отображение вашей базы данных (ваша организация делает это)