Symfony2 MVC: где мой код принадлежит?

Question

Я прошу уточнить, следует ли помещать код в контроллер, сущность или предоставлять услугу.

У меня есть объекты 'cardset' и 'card' (многие из которых встроены впервый, MongoDB), представленный обычными классами / объектами PHP.Они содержат атрибуты, например, 'id', 'postal_address'.

У меня есть метод, который генерирует PDF карты.В настоящее время у меня есть это внутри объекта 'Card', поэтому из контроллера я могу позвонить:

$card->makePDF()

Мне это кажется чистым и ОО, но я подозреваю, что ошибаюсь.

ЕслиЯ помещаю всю логику в контроллер, который становится длинным и громоздким, и я не уверен, что контроллер - это место для методов, которые воздействуют на мои объекты.Это то, для чего нужны сервисы?

Чтобы попытаться подвести итог: должен ли объект знать все обычные вещи, которые он может сделать «для себя», и иметь их внутри как функции-члены, или же методы должны передаваться объекту в другом местедействовать наЕсли да, то где хранить эти методы?

Я почти уверен, что это не «Репозиторий», потому что он, похоже, просто помогает извлекать / хранить сущности.

Спасибо!

Answer 1

Краткий ответ:

Генерация PDF должна быть службой, а не методом объекта.

Более длинный ответ:

В целом, и особенно в Symfony2, модели должны использоваться только для хранения данных. Контроллеры используются для манипулирования отношениями между моделями, а представления используются для представления данных в читаемой человеком или компьютерной форме. Услуги предназначены для вещей, которые на самом деле не вписываются ни в один из вышеперечисленных - вещей, которые не имеют отношения к состоянию вашего веб-приложения.

Хорошим примером является отправка электронных писем. Письма содержат данные (модель). Пользователи отправили электронные письма (контроллер). Письма выглядят определенным образом (просмотр). Однако фактическая отправка электронных писем не зависит от состояния веб-приложения (все, что знает служба, это то, что ее попросили отправить это письмо этим людям). Таким образом, имеет смысл наличие независимой службы, которая просто обрабатывает отправку электронных писем.

Аналогично, процесс создания PDF-файлов не зависит от состояния веб-приложения. Генератору PDF не нужно знать, что происходит в вашем приложении, он просто знает, что его попросили сделать PDF.

Answer 2

• Symfony2 НЕ является структурой MVC (как сказал сам Фабьен) именно потому, что она дает все V (веточка) и C (контроллеры), но НЕ дает часть M. Часть M «свободна» для сборки по вашему желанию.

• Существует большое замешательство, люди "думают", что Доктрина ЕСТЬ модель. Но это не правда. То, что мы делаем, это ДВА каталога в Bundle, один называется «Документ» для классов Doctrine-ODM, а другой - «Модель», где находится «бизнес-логика».

Лично я вижу, что $ card-> makePDF () имеет смысл ...

Но $ card должна быть "моделью карты", которая наследует или имеет базовый объект "карта данных", который является классом доктрины.

Вы можете играть с наследованием, или с интерфейсами, с создателями или с тем, что вы хотите связать «модель-карта» с «картой данных», но ключ в том, что «доктрина - это не модель БИЗНЕС», это просто слой персистентности и ваша модель - это «простые классы», которые вы можете создать, чтобы обернуть ваши данные внутри и заставить контроллеры использовать модель, а не данные.

Answer 3

Если вы будете следовать SOLID принципам, вы попадете на SRP , в котором говорится, что ваш класс должен нести одну ответственность.

Я думаю, что очевидно, что создание одного PDF-файла отличается от моделирования данных и отображения вашей базы данных (это делает ваша сущность)