Уместно ли для класса Factory также включать функцию извлечения данных из базы данных
Мое обоснование для этого заключается в том, что если фабрике поручено создавать определенный продукт, то он также долженнести ответственность за получение данных, необходимых для создания этого продукта.Но я не уверен на 100%, если это правильно.
A product для извлечения из базы данных - это не тривиальный объект, это домен модель .Доменная модель (она же бизнес-модель, то есть сущность (которая может указывать на конкретный экземпляр)) принадлежит вашему уровню домена (он же бизнес-уровень).В связи с этим есть некоторые шаблоны, с которыми вы должны быть как минимум знакомы ...
Образец активной записи нарушает принцип единой ответственности , заставляя вас реализовать логику доступа к базе данных в вашем доменесмоделировать и тесно связать их.
В идеале, чтобы избежать вышеизложенных недостатков из-за немного повышенной сложности (только в краткосрочной перспективе), мы разделяем логику доступа к базе данных на дополнительный уровень, данные уровень доступа .Одним из основных компонентов этого уровня является средство отображения данных, которое в нашем контексте (операция READ) отвечает за извлечение данных из базы данных и сопоставление их с новым экземпляром модели домена, вашим конкретным продуктом (сущностью),В более общем смысле он инкапсулирует операции CRUD в базу данных, абстрагируя эту базу данных.Его входы и выходы API являются объектами сущностей и, возможно, Объектами запросов .
. При желании в специальном устройстве отображения данных могут использоваться такие шаблоны, как:
- Unit OfРабота
- Ленивая загрузка
- Карта удостоверений
- Транзакция
- Стратегии блокировки
- Отображение метаданных
В качестве альтернативы, должен ли существовать класс репозитория, ответственный за извлечение данных из базы данных, которые затем могут быть переданы на завод для сборки в требуемый продукт?Использование класса репозитория кажется в этом случае немного чрезмерным, так как у нас есть класс, который будет содержать большое количество различных частей данных, которые затем должны быть отправлены в фабричный класс.
Репозиторий не часть вашего уровня доступа к данным, но вашего уровня домена.Так что это клиент вашего уровня доступа к данным.Он не инкапсулирует какую-либо логику доступа к базе данных, но использует средство отображения данных.
Репозиторий инкапсулирует логику запросов для конкретной модели домена плюс набор сущностей в памяти, которые вы ранее извлекли.Очень простой пример:
class ProductRepository
{
private $productCollection;
public function findById($id)
{
if (!$this->productCollection->has($id)) {
$product = $this->dataMapper->get(new Query(Product::class, $id));
$this->productCollection->add($product);
return $product;
}
return $this->productCollection->get($id);
}
}
Наконец, мы можем инкапсулировать логику доступа к базе данных в шлюз данных таблиц и использовать ее на фабрике.Это приведет к решению, аналогичному Gonen I's .Это просто реализовать, но могут быть недостатки по сравнению с решением для отображения данных.Я никогда не реализовывал, не использовал и даже не изучал этот подход, поэтому я не могу много рассказать ...
Вы бы наверняка многому научились, пытаясь реализовать все это самостоятельно, и я быпризываю вас, но имейте в виду, что если вам нужно серьезное решение, ORM могут быть вам интересны.
Если вы хотите узнать обо всем этом больше, я рекомендую MartinКнига Фаулера «Образцы корпоративной архитектуры приложений» , кратко изложенная здесь: https://www.martinfowler.com/eaaCatalog/index.html