СУХОЙ: как использовать этот код в нескольких объектах проекта Symfony2? Черты?

У меня есть этот повторяющийся кусок кода, который будет использоваться более чем в одной сущности в моем проекте 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 для того чтобы поймать его на контроллере и отправить обратно на просмотр?
  • Нужно ли мне также определить Suscriber? Зачем?

Это новые темы для меня, поэтому мне нужен какой-то совет

2

Решение

Следующий @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
}
1

Другие решения

Бизнес-логика не превращается в сущности.

Черты не помогут вам, потому что дублирование кода — это плохо, злоупотребление чертами имо еще хуже.

Однажды я подумал, стоит ли мне использовать черты, и отправил вопрос по codereview (https://codereview.stackexchange.com/a/74195/56686). Я еще не наткнулся на действительный вариант использования черт в моих приложениях.

Я советую вам сделать услугу и поставить свою логику там.
Документация: http://symfony.com/doc/current/book/service_container.html

Поскольку вы не можете вызывать службы Symfony из обратных вызовов doctrine lifecycle, вам придется их отбросить.

Возможно, вы не захотите запустить свой поисковик по выбору, чтобы найти пошаговое руководство.

0

По вопросам рекламы [email protected]