Какой шаблон проектирования больше подходит для загрузки связанных сущностей?

Question

[homedistiller]

Без привязки к какому-либо фреймворку.

Например есть сущность заказа, в ней есть идентификаторы товаров, идентификатор покупателя и т.д. Как это все красиво и правильно реализовать, используя современные подходы?

Вот пример кода:

class OrderEntity
{
	protected $id = 0;
	protected $member_id = 0;
	// массив идентифкаторов
	protected $items_ids = [];
}

class ItemEntity
{
	protected $id = 0;
	protected $name = '';
}

class MemberEntity
{
	protected $id = 0;
	protected $name = '';
}

class OrderService
{
	public function getOrder($id): OrderEntity
	{
		return $this->mapper->getOrder($id);
	}
}

$service = new OrderService();
$order = $service->getOrder(1);

Заказ есть. А как теперь лучше получить список товаров и покупателя. Где эта загрузка должна быть? В каком классе?

И все то же самое, но только для коллекции заказов.

Answer 1

[Максим Федоров]

1. Как-то у Вас сущности живут отдельной жизнью друг от друга. По сути сейчас Вы перенесли структуру своей базы данных на объекты, а это не правильно. Сущность заказа должна агрегировать в себя сущности позиций заказа и покупателя, а не просто содержать их идентификаторы. Например:

class OrderEntity
{
    /**
     * @var integer Идентификатор заказа
     */
    protected $id;
    
    /**
     * @var MemberEntity Объект покупателя
     */
    protected $member;
    
    /**
     * @var ItemEntity Массив позиций заказа
    protected $items = [];
}

2. Получение данных из базы данных в объект должно быть реализовано в каком-нибудь репозитории или в каком-нибудь датамаппере. Почитайте про эти паттерны. Но вообще лучше взять какую-нибудь вменяемую ORM что бы избежать кучи гемора.
3. По названиям классам - не добавляйте в них суфикс Entity, код становиться из-за этого более нагроможденным, лучше используйте пространства имен

Comments

[homedistiller]

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

[Максим Федоров]

homedistiller,
Давайте на примере заказа. Что такое объект заказа? это агрегат который содержит в себе какие-то свои данные, сущности покупателя и позиций заказа. Соответственно маппер заказа должен собирать весь объект заказа со всеми агрегируемыми сущностями, но при этом он не может непосредственно лезть в базу для получения данных о покупателе и формировать объект покупателя, ибо это нарушение принципа единой ответственности. Этим должен заниматься маппер покупателя. Соответственно что бы правильно сформировать объект заказа, маппер заказа должен знать о маппере покупателя и запрашивать у него объект покупателя который будет добавлен в заказ.

Более подробнее по этой теме можете почитать у Фаулера в книге "Patterns of Enterprise Application Architecture"

[homedistiller]

Все верно, меня интересуют подробности реализации на PHP с примерами.

Answer 2

[dmitriy]

У меня были попытки реализации датамаппера, в рамках изучения,но на самом деле нужно что то более готовое, стабильное. Если найдете либу для маппинга данных, поделитесь.

Comments

[homedistiller]

Как то у тебя сложновато получилось... На пхпклабе доктрину рекомендовали, но она мне сложноватой показалась и требовательной к ресурсам, сам проверял. В доктрине понравилось, что знания о том как хранятся данные может хранить сама сущность, но там правда в виде аннотаций. На гитхабе понравилась такая реализация https://github.com/fordnox/mikron все предельно просто и понятно, но функционал сильно слабоват. А так ничего очень простого и относительно универсального там не нашел.