У меня есть этот повторяющийся кусок кода, который будет использоваться более чем в одной сущности в моем проекте Symfony2, поэтому будет неплохо применить какой-нибудь DRY, если это возможно, конечно, и я думаю, что в Черты PHP.
private static $preDeletedEntities;// static array that will contain entities due to deletion.
private static $deletedEntities;// static array that will contain entities that were deleted (well, at least the SQL was thrown).
/**
* This callback will be called on the preRemove event
* @ORM\PreRemove
*/
public function entityDueToDeletion()
{
// This entity is due to be deleted though not deleted yet.
self::$preDeletedEntities[] = $this->getId();
}
/**
* This callback will be called in the postRemove event
* @ORM\PostRemove
*/
public function entityDeleted()
{
// The SQL to delete the entity has been issued. Could fail and trigger the rollback in which case the id doesn't get stored in the array.
self::$deletedEntities[] = $this->getId();
}
public static function getDeletedEntities()
{
return array_slice(self::$preDeletedEntities, 0, count(self::$deletedEntities));
}
public static function getNotDeletedEntities()
{
return array_slice(self::$preDeletedEntities, count(self::$deletedEntities)+1, count(self::$preDeletedEntities));
}
public static function getFailedToDeleteEntity()
{
if(count(self::$preDeletedEntities) == count(self::$deletedEntities)) {
return NULL; // Everything went ok
}
return self::$preDeletedEntities[count(self::$deletedEntities)]; // We return the id of the entity that failed.
}
public static function prepareArrays()
{
self::$preDeletedEntities = array();
self::$deletedEntities = array();
}
Это код, который я имею в виду:
use Doctrine\ORM\Mapping as ORM;
/**
* @ORM\HasLifecycleCallbacks()
*/
trait DeleteLifeCycleCallbacksTrait
{
// write things here
}
Но будет ли аннотация применяться к сущности? Это нормально? Что бы вы сделали, чтобы избежать повторения кода?
РЕДАКТИРОВАТЬ: Пытаясь найти лучший подход
Имея некоторые идеи от @Cerad пользователь и потому, что, как говорит документация Слушатели событий жизненного цикла намного мощнее, чем простые обратные вызовы жизненного цикла тогда я начну играть с ними.
Итак, во-первых, цель этого Lifecycle Callbacks|Listener|Suscribers
будет хранить идентификатор каждого сохраняемого объекта, чтобы я мог каким-то образом получить его и отправить обратно в представление из контроллера. В качестве простого визуального примера, скажем, я отправляю из представления в контроллер этот массив значений (1, 2, 3, 4, 5)
и по какой-то причине X были сохранены только 1, 4 и 5 (значит, было полное удаление из БД) в БД, верно?
Скажем также, что я буду использовать прослушиватель событий в Producto
юридическое лицо. Итак, без тестирования и просто получения кода из примеров, код должен быть примерно таким Listener
:
use Doctrine\ORM\Event\LifecycleEventArgs;
use Entity\Producto;
class StoreDeletedIds
{
private $deletedItems = [];
public function postDelete(LifecycleEventArgs $args)
{
$entity = $args->getEntity();
$entityManager = $args->getEntityManager();
if ($entity instanceof Producto) {
array_push($deletedItems, $entity->getId());
}
}
}
Мои вопросы относительно этого:
$deletedItems
очищается каждый раз, когда слушатель вызывается доктриной?$deletedItems
для того чтобы поймать его на контроллере и отправить обратно на просмотр?Это новые темы для меня, поэтому мне нужен какой-то совет
Следующий @PeterPopelyshko прокомментируйте это решение, с которым я пришел, просто определите абстрактный класс Model\DeleteLifeCycleCallbacks.php
и поместите код внутри:
use Doctrine\ORM\Mapping as ORM; // not so sure if this is need here
abstract class DeleteLifeCycleCallbacks
{
private static $preDeletedEntities;// static array that will contain entities due to deletion.
private static $deletedEntities;// static array that will contain entities that were deleted (well, at least the SQL was thrown).
/**
* This callback will be called on the preRemove event
* @ORM\PreRemove
*/
public function entityDueToDeletion()
{
// This entity is due to be deleted though not deleted yet.
self::$preDeletedEntities[] = $this->getId();
}
/**
* This callback will be called in the postRemove event
* @ORM\PostRemove
*/
public function entityDeleted()
{
// The SQL to delete the entity has been issued. Could fail and trigger the rollback in which case the id doesn't get stored in the array.
self::$deletedEntities[] = $this->getId();
}
public static function getDeletedEntities()
{
return array_slice(self::$preDeletedEntities, 0, count(self::$deletedEntities));
}
public static function getNotDeletedEntities()
{
return array_slice(self::$preDeletedEntities, count(self::$deletedEntities)+1, count(self::$preDeletedEntities));
}
public static function getFailedToDeleteEntity()
{
if(count(self::$preDeletedEntities) == count(self::$deletedEntities)) {
return NULL; // Everything went ok
}
return self::$preDeletedEntities[count(self::$deletedEntities)]; // We return the id of the entity that failed.
}
public static function prepareArrays()
{
self::$preDeletedEntities = array();
self::$deletedEntities = array();
}
}
Затем используйте его следующим образом:
/**
* @ORM\Entity
* @ORM\HasLifecycleCallbacks()
*/
class Producto extends Model\DeleteLifeCycleCallbacks
{
// entity methods and properties here
}
Бизнес-логика не превращается в сущности.
Черты не помогут вам, потому что дублирование кода — это плохо, злоупотребление чертами имо еще хуже.
Однажды я подумал, стоит ли мне использовать черты, и отправил вопрос по codereview (https://codereview.stackexchange.com/a/74195/56686). Я еще не наткнулся на действительный вариант использования черт в моих приложениях.
Я советую вам сделать услугу и поставить свою логику там.
Документация: http://symfony.com/doc/current/book/service_container.html
Поскольку вы не можете вызывать службы Symfony из обратных вызовов doctrine lifecycle, вам придется их отбросить.
Возможно, вы не захотите запустить свой поисковик по выбору, чтобы найти пошаговое руководство.