Как правильно реализовать модель в Symfony2 на базе MVC?

Question

[Александр Стрелов]

Я разобрался, что есть в Symfony2 View, а где Controller, но не могу понять где и как создавать свою модель логики? Знаю, что есть сущности доктрины в папке Entity, которые предоставляют интерфейс к БД с геттерами и сеттерами, но ведь это еще не модель. Модель как раз должна описывать всю логику работы и не с одной таблицей данных, а со всеми возможными связями и ограничениями. Но куда выносить эту модель?


Если отдельно в папку Models, то как в классах модели получить доступ к контейнеру служб, чтобы использовать ту же Doctrine, если класс модели не наследовать от Controller (это же модель, а не контроллер!)? Или нужно реализовывать модель «рядом» с Entity, наследуя от них классы? Мне представляется, что основная часть логики должна быть именно в отдельной модели, а не в контроллере или я, что-то не правильно понимаю?


Прошу поделиться знаниями опытных разработчиков по этому вопросу и помочь в этом вопросе.

Answer 1

[JekaRu]

Логику модели обычно выносят в сервисный слой
Для работы с базой используют классы репозитарии.
Сейчас популярен подход похожий на ваш c UserModel, создают класс — менеджер модели, туда инкапсулируют репозитарий модели, EntityManager итд…
Получается очень удобно вынести в него весь сервисный слой.
Примеры:
github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Doctrine/UserManager.php
github.com/KnpLabs/KnpBundles/blob/master/src/Knp/Bundle/KnpBundlesBundle/Manager/BundleManager.php

Comments

[Александр Стрелов]

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

Answer 2

[Сергей Протько]

Модель в ключе MVC Это просто собирательное от бизнес логики скорее. По сути в Symfony вся логика должна храниться в сервисах.

Entity — это просто как структура данных, сама она логикой тоже может обладать, но минимально, так как ей не доступны сервисы.

Model в контексте форм — это что-то типа Data transfer object, то бишь некий объект, который содержит данные в нужном формате. В большинстве случаев моделью для форм являются сущности.

Контроллеры это просто контроллеры, тут все раскрыто довольно хорошо в документации.

Логику же, если по хорошему, нужно выносить в сервисы. Почти все можно вынести из контроллера в ивент листенеры, отдельные служебные сервисы, хэндреры форм (для дедублицирования кода в контроллерах, правда не часто помогает). Словом, тут все очень и очень зависит от проекта. Но сущность должна только хранить данные, и никак их не изменять. Можно только дополнительные геттеры писать, которые производят небольшие манипуляции с данными.

Comments

[Александр Стрелов]

Т.е. создание сервиса, что я привел выше это верное направление?

[Сергей Протько]

Ну ваш пример конкретно не годится. Логика по работе с выборками, с коллекциями пользователей, с базой и т.д. должна выноситься в репозиторий для вашей сущьности.

Опять же о пользователях — хороший пример — хэширование паролей. Скажем, вы добавили в вашу сущьность поле plainPassword которое заполняется при регистрации скажем. Затем, перед сохранением данных в базу, вызывается ваш сервис, который (если конечно plainPassword не null) и сгенерит новый хэш. Таким образом вся лолгика по хэшированию будет вынесена в отдельный сервис, который вручную не будет вызываться, а будет вызываться автоматически по событию.

[Сергей Протько]

plainPassword к слову не должен сохраняться в базу, это просто поле для формы.

[Александр Стрелов]

Выборка в примере это не то, что планируется делать, там как раз думается выполнять различные подготовительные вычисления, получение доп. данных из других сущностей и выполнение добавлений/обновлений данных в репозитории.

[Сергей Протько]

Это стоит вынести либо в ивент листенер по onFind или же в репозиторий.

[TrueDrago]

А есть ли смысл выносить наружу, в сервисы, простые операции типа хеширования паролей?

[Александр Стрелов]

С событиями я еще не особо разбирался, где об этом можно почитать с примерами?

[TrueDrago]

Да где и про остальное — тут или тут для doctrine

[Александр Стрелов]

Ознакомился, хороший инструмент Event Dispatcher, можно воткнуть callback на разные события как в ядре, так и в Доктрине, очень подойдет для подготовки данных до и после основной «работы», но все же, если у меня есть логика работы с несколькими сущностями забивать ее в конроллер нельзя, так как подобная вещь может быть использована и в другом контроллере, что я сейчас и наблюдаю в коде моих коллег по цеху, это дело нужно выносить в отдельный сервис, я так понимаю, и обращаться к нему из всех контроллеров соответственно.

Answer 3

[Владимир Чернышев]

Использую доктриновские сущности, нашпигованные методами бизнес-логики. Если для бизнес-логики нужны какие-то сущности, не связанные с текущей схемой данных, то передаю их как параметры методам, предварительно вытаскивая из репозиториев в контроллерах. Сами сущности ничего не знают о хранении их в репозиториях, обычные POPO, вся логика хранения обеспечивается в контроллере.

Сервисы использую когда в методах различных сущностей появляется дублирование кода или просто непонятно к какой сущности отнести тот или иной метод — типичный пример: перевод со счёта на счёт, оба счёта в принципе равноправны, и что метод DebetTo в источнике, что метод CreditFrom в получателе будет выглядеть некрасиво, особенно если будет ещё и третий счёт, на который перечисляется комиссия за транзакцию, а создание класса транзакции в модели нецелесообразно — прямой кандидат в сервисы. Вообще сервисы рассматриваю как функции.

Answer 4

[TrueDrago]

Если логика относится непосредственно к сущности, взятой из базы данных, я её запихиваю в Entity.
Уж не знаю, насколько этот подход правилен, т.к. сам еще новичек в Symfony, но мне это решение кажется вполне логичным.
Насколько я понимаю, тут Models скорее используются для создания абстрактных сущностей или интерфейсов, чтобы потом от них отнаследовать конкретные реализации, будь то Doctrine или что-то еще.

Comments

[Александр Стрелов]

Вы дописываете класс сущности с учетом своей логики или создаете производный от него? Вообще встречал где-то упоминания, что сущности Doctrine не рекомендуется трогать.

[TrueDrago]

Я дописываю в файл сущности требуемые свойства\методы, либо модифицирую существующие — ничего страшного в этом не вижу.
Даже в документации, например, с которой вчера работал, приведен пример, где для работы с ассоциациями дописывается функционал прямо в сущность: http://doctrine-orm.readthedocs.org/en/latest/reference/working-with-associations.html#association-management-methods

[TrueDrago]

Или вот пример, как у меня добавление оценок к сущности происходит:

<?php
class MyEntity {
/*** Other code here ***/
	public function addPoint($point) {
		$total_points = $this->getAvgPoints() * $this->getReviewsnum();
		$new_reviewsnum = $this->getReviewsnum() + 1;
		$new_points = ($total_points + $point) / $new_reviewsnum;
		
		$this->setReviewsnum($new_reviewsnum);
		$this->setAvgPoints($new_points);
		
		$parent = $this->getParent();
		if ($parent) 
			$parent->addPoint($point);
	}
}
?>

[Александр Стрелов]

А как вы обращаетесь к другим сущностям, которых не связанны ключами с текущей?
Вы вносите изменения в БД прямо из класса сущности?

[TrueDrago]

Если сущность ничего не знает о другой сущности, то она ей и не должна оперировать.
Я это перелагаю на Controller, или Command (для CLI приложений) или любой другой класс.

[Александр Стрелов]

А как сущность выполнит обновление себя или «соседа»?

[TrueDrago]

Обновление выполнит класс, который сущностью управляет:

<?php
	$entity = new MyEntity();
	$entity->setAttr('some attr');
	$em->persist($entity);
	$em->flush();
?>

Для «соседа» так же я думаю. Хотя если она знает о соседе, то возможно будет правильней из неё свойства соседа изменять. Может кто-то подскажет точнее вам.

Answer 5

[TrueDrago]

В таком случае, либо так, либо как сказали выше, использовать EntityManager (я бы выбрал 2-е в большинстве случаев, но зависит от задачи всё же)