Я часто сталкиваюсь с таким кодом (ссылка Тонкий учебник на github).
TicketMapper.php
class TicketMapper extends Mapper
{
public function getTickets() {
$sql = "SELECT t.id, t.title, t.description, c.component
from tickets t
join components c on (c.id = t.component_id)";
$stmt = $this->db->query($sql);
$results = [];
while($row = $stmt->fetch()) {
$results[] = new TicketEntity($row);
}
return $results;
}
/**
* Get one ticket by its ID
*
* @param int $ticket_id The ID of the ticket
* @return TicketEntity The ticket
*/
public function getTicketById($ticket_id) {
$sql = "SELECT t.id, t.title, t.description, c.component
from tickets t
join components c on (c.id = t.component_id)
where t.id = :ticket_id";
$stmt = $this->db->prepare($sql);
$result = $stmt->execute(["ticket_id" => $ticket_id]);
if ($result) {
return new TicketEntity($stmt->fetch());
}
}
public function save(TicketEntity $ticket) {
$sql = "insert into tickets
(title, description, component_id) values
(:title, :description,
(select id from components where component = :component))";
$stmt = $this->db->prepare($sql);
$result = $stmt->execute([
"title" => $ticket->getTitle(),
"description" => $ticket->getDescription(),
"component" => $ticket->getComponent(),
]);
if (!$result) {
throw new Exception("could not save record");
}
}
}
TicketEntity.php
class TicketEntity
{
protected $id;
protected $title;
protected $description;
protected $component;
/**
* Accept an array of data matching properties of this class
* and create the class
*
* @param array $data The data to use to create
*/
public function __construct(array $data) {
// no id if we're creating
if (isset($data['id'])) {
$this->id = $data['id'];
}
$this->title = $data['title'];
$this->description = $data['description'];
$this->component = $data['component'];
}
public function getId() {
return $this->id;
}
public function getTitle() {
return $this->title;
}
public function getDescription() {
return $this->description;
}
public function getShortDescription() {
return substr($this->description, 0, 20);
}
public function getComponent() {
return $this->component;
}
}
Моя текущая практика не использует классы сущностей, а мои методы сопоставления просто возвращают stdClass, как показано ниже:
class TicketMapper extends Mapper
{
public function getTickets() {
$sql = "...";
$stmt = $this->db->query($sql);
return $stmt->fetchAll(PDO::FETCH_OBJ);
}
public function getTicketById($ticket_id) {
$sql = "...";
$stmt = $this->db->prepare($sql);
$result = $stmt->execute(["ticket_id" => $ticket_id]);
return $stmt->fetch(); //Assuming my PDO is configured to return an object only
}
public function save($ticket) {/* no change */}
}
Почему результаты базы данных часто заключаются в какой-либо класс сущности? Есть ли какие-то критерии, по которым можно было бы определить, делать это или нет?






Инкапсуляция: класс - это полезный пакет, содержащий код и соответствующие данные вместе, изолированные от всего остального. Это упрощает перемещение без поиска точных переменных, без конфликтов с существующим кодом / данными.
Конечно, классы имеют и другое применение, но в средах сценариев, таких как PHP, я думаю, что это самое большое преимущество.
Повторное использование кода
Наследование
Более простая ремонтопригодность
и т. д. Проведите небольшое исследование, это забавная вещь, чтобы узнать
Смысл картограф данных заключается в том, чтобы действовать как постоянный уровень между вашей бизнес-логикой и вашим хранилищем. Он заполняет или хранит данные в объектах сущности.
И у этих сущностей есть несколько целей:
инкапсуляция: у вас есть возможность отслеживать и контролировать, как данные, содержащиеся в объектах, доступны и изменяются
проверка: обеспечение соответствия состояния объекта бизнес-правилам и способность определять, вошла ли сущность (или собирается войти) в недопустимое состояние.
контракты: вы можете использовать подсказки типов, чтобы определить, какие другие модули (классы, функции) могут использовать эту сущность и какие типы вещей она может принимать в качестве параметров. Вы также можете определить, какой интерфейс должен реализовывать заменитель этого объекта.
поведение: объект часто будет иметь связанное поведение (или бизнес-логику), например: операция $article->markAsApproved() не будет тривиальным установщиком, а вместо этого произведет атомарное изменение состояния.
Что касается критериев ... ну ... "вы используете ООП или нет" было бы наиболее близким. stdClass - это просто прославленный массив без поведения.
Вам, наверное, стоит посмотреть эта лекция.
Спасибо, tereško, я действительно увидел некоторые преимущества валидации и контрактов (однако я думал, что ответственность за валидацию должна нести служба, а не организация). Только что увидел, как всплыла ваша цель поведения, что, я думаю, имеет смысл. Вы всегда так делаете, если у вас нет веских причин не делать этого? Смотрю лекцию прямо сейчас.
Проверка - это очень расплывчатый термин :( потому что он фактически охватывает разные типы вещей. Например, «выглядит ли адрес электронной почты правильно?» Будет проверяться сущностью, а «кто-то уже зарегистрировал это электронное письмо?» Будет сделано в картографе ( потому что это будет проверка целостности данных). И такие вещи, как «можете ли вы начать оформление заказа с 0 товарами в корзине», будут проверяться службой.
Спасибо, gmbc. Я определенно вижу преимущества классов, сокращение скриптов за счет наследования и инкапсуляции, но никогда не вижу каких-либо функций, реализованных с помощью этих классов сущностей, кроме пары геттеров и сеттеров, что заставляет меня задаться вопросом, зачем их использовать.