ООП: Правильно ли архитектурно так делать?

Привет!

Работая в некоторых системах, мне часто приходится делать выборки из различных источников (nosql база данных, внешний api (или какие-то внутренних модулей), и т.д.) и чаще всего, результатом таких выборок - это массив параметров и значений.

В больших проектах мне сложно работать с этими массивами из-за множества проблем с этим.

Поэтому, я оборачиваю все эти данные в объекты:

Например:

У меня есть метод модуля работы с заказами, который возвращает заказ по его идентификатору.
Заказа - это множество параметров самого заказа, его покупателя, товары и т.д.

При проектировании, у меня получается следующее:
<?php
class Order {
	private array $order_fields;
	private Buyer $buyer;
	private BasketItems $basket_items;

	public function __construct(array $order_fields, Buyer $buyer, BasketItems $basket_items) {
		$this->order_fields = $order_fields;
		$this->buyer = $buyer;
		$this->basket_items = $basket_items;
	}

	public function getId(): int { return $this->order_fields['order_id']; }
	public function getAmount(): float { return $this->order_fields['order_amount']; }
	public function getBuyer(): Buyer { return $this->buyer; }
	public function getBasketItems(): BasketItems { return $this->basket_items; }
}

class Buyer {
	private array $buyer_fields;

	public function __construct(array $buyer_fields) {
		$this->buyer_fields = $buyer_fields;
	}

	public function getId(): int { return $this->buyer_fields['id']; }
	public function getFullName(): string { return $this->buyer_fields['full_name']; }
	public function getPhone(): string { return $this->buyer_fields['phone']; }
}
// ...


В результате, на каком-то уровне приложения, происходит выборка, а дальше создаются все необходимые объекты, и внедряются друг в друга. (кстати, как называется этот слой приложения, и в чьей зоне ответственности эта задача ?)

Меня смущает множество классов, которые в себе очень редко содержат какую-то бизнес-логику.
И их основная задача - чаще всего получать в конструктор массив данных для текущей сущности (иногда уже готовый объект внедряется, который заранее был таким же образом собран) , и возвращать через геттеры. Возможно, это нормально, так и должно быть ? или как архитектурно правильно решать подобное?
  • Вопрос задан
  • 1671 просмотр
Решения вопроса 3
Vamp
@Vamp
Возможно, это нормально, так и должно быть ? или как архитектурно правильно решать подобное?

Это нормально. Безликие массивы становятся осмысленными сущностями. Такой код становится проще понимать и поддерживать.

Используемый вами подход называется data transfer object (DTO). Широко распространенная практика. DTO отлично сочетается с иммутабельностью, которая присутствует в ваших классах.

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

В результате, на каком-то уровне приложения, происходит выборка, а дальше создаются все необходимые объекты, и внедряются друг в друга. (кстати, как называется этот слой приложения, и в чьей зоне ответственности эта задача ?)

Называется ORM. Находится в ответственности ORM слоя/фреймворка.
Ответ написан
profesor08
@profesor08 Куратор тега PHP
Вот это order_fields поле должно быть объектом. В целом, если хочется удобства, целостности данных и надежности, то неплохо бы вместо ассоциативных массивов использовать обычные объекты, самые простые с обозначенными типами для полей, да хоть с паблик полями, или сделать их readonly.
Ответ написан
DollyPapper
@DollyPapper
Оборачивать массивы какой нибудь выборки в объекты для передачи куда нибудь в другой слой или сериализации и передачи по сети это совершенно нормально, ничего в этом такого нет. Скажу даже больше, это оборачивание в "обьект" даже называние специальное имеет - DTO (DataTransferObject), паттерн. Но путать DTO и обьекты не стоит, т.к. по факту это структуры данных. В С#, С и каких нибудь еще языках для этого есть даже ключевое слово struct, но в пыхе мы такого не имеем по этому заворачиваем в обьекты.
кстати, как называется этот слой приложения, и в чьей зоне ответственности эта задача

Зависит от вашей архитектуры. Если у вас богатая доменная модельно, то эти методы выборки и создания могут быть прям в модели, если у вас анемичная модель, то существует слой бизнес сервисов в которые выносятся методы работы с вашей бизнес логикой.
Меня смущает множество классов, которые в себе очень редко содержат какую-то бизнес-логику
, судя по этому у вас как раз второе. Однако сама выборка из базы это явно не зона ответственности модели, для этого не плохо бы вынести это всё дело в persistanse слой.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
YCLIENTS Москва
от 200 000 до 350 000 ₽
Ведисофт Екатеринбург
от 25 000 ₽
ИТЦ Аусферр Магнитогорск
от 100 000 до 160 000 ₽
24 апр. 2024, в 20:57
3000 руб./за проект
24 апр. 2024, в 20:35
5000 руб./за проект