Любое программное обеспечение разрабатывается под конкретную предметную область, например, система аналитики оперирует понятиями "просмотр", "сессия", "воронка", "когорта", а интернет-магазин — "товар", "категория", "платежный шлюз". Все вместе они составляют онтологию предметной области (говорят модель предметной области). Кроме самих понятий онтология содержит и описание их связей. Например, сущность «Пользователь» связана с сущностью «Покупка» как «один ко многим». То есть один пользователь может выполнить сколько угодно покупок, но каждая покупка принадлежит только одному пользователю.
Модель предметной области — основа коммуникации и взаимопонимания между членами команды. Она не зависит ни от языка программирования, ни от программирования вообще. Не важно кто общается: программисты между собой или программисты с заказчиками, менеджерами или дизайнерами. Все вместе они оперируют сущностями и связями предметной области и бизнес-правилами, используемыми в данной программе. К таким правилам может относиться автоматическое включение скидки при заказе от определенного объема товаров.
Важно понимать, что модель на то и модель, что она отражает лишь часть предметной области с некоторой детализацией. Причем, в программах из одной области, но от разных производителей, модель может быть разной. Конечно же, в таких областях, как бухгалтерия, есть некоторый набор фиксированных сущностей, их связей и правил работы, но есть и те вещи, где возможны вариации. В менее формальных областях таких возможностей еще больше.
Приведу несколько примеров из Хекслета. Количество сущностей — больше сотни, количество связей — много сотен, количество правил посчитать сложно, их тоже много.
На основе модели предметной области формируется модель данных в коде. Создаются сущности, определяются их связи. Затем строится рабочий код, который оперирует сущностями, исходя из требований (бизнес-правил). На этом этапе возникает вопрос: а как эти сущности отображаются («мапятся» от англ. "map") на базу данных, ведь именно там в конечном итоге все хранится.
Самый простой вариант — создавать по таблице на каждую сущность и связывать их через внешние ключи. Именно так и делают в большинстве проектов, но не руками, а используя ORM (object-relation mapper). По сути, ORM — фреймворк для данных. С помощью него описываются сущности и их связи, определяется то, как сущность отображается на базу данных (как правило, в полуавтоматическом режиме). ORM берет на себя серьезную часть работы по генерации SQL-запросов, по извлечению данных и кастингу (преобразование типов базы данных в типы целевого языка и обратно), по автоматическому извлечению связей. В итоге получается, что ORM прячет всю работу с базой данных (требуя только правильного конфигурирования) и сама выполняет все необходимые запросы. В сложных случаях их все равно приходится писать самостоятельно, но, как минимум, ORM содержат в себе query builder, который упрощает генерацию sql.
В php таких ORM довольно много, некоторые из них разрабатывались под конкретные фреймворки и поставляются с ними. Посмотрим на пример с фреймворком Doctrine2.
Определение сущности Photo:
<?php
// src/Entity/Photo.php
namespace App\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* @ORM\Entity
* @ORM\Table(name="photos", uniqueConstraints={@ORM\UniqueConstraint(name="photo_slug", columns={"slug"})}))
*/
class Photo
{
/**
* @ORM\Id
* @ORM\Column(name="id", type="integer")
* @ORM\GeneratedValue(strategy="AUTO")
*/
protected $id;
/**
* @ORM\Column(type="string", length=64)
*/
protected $title;
/**
* @ORM\Column(type="string", length=150)
*/
protected $image;
/**
* @ORM\Column(type="string", length=100)
*/
protected $slug;
/**
* Get photo id
*
* @ORM\return integer
*/
public function getId()
{
return $this->id;
}
/**
* Get photo title
*
* @ORM\return string
*/
public function getTitle()
{
return $this->title;
}
/**
* Get photo slug
*
* @ORM\return string
*/
public function getSlug()
{
return $this->slug;
}
/**
* Get photo image
*
* @ORM\return string
*/
public function getImage()
{
return $this->image;
}
}
Использование:
<?php
$app->get('/photos', function() {
// Получаем из базы список всех фотографий
$photos = $this->entityManager->getRepository('App\Entity\Photo')->findAll();
// Передаем их в шаблон
return $this->renderer->render($response, "/photos.phtml", ['photos' => $photos]);
});
Сказать, что описанное выше сложно для новичка — ничего не сказать. Перед работой с ORM нужно сначала научиться основам баз данных. Причем не через программирование, а через прямую работу с базой. Познакомиться с понятием нормализации, внешними и первичными ключами, индексами, планом запроса и научиться работать с sql как для изменения структуры базы данных, так и для манипулирования данными внутри базы. Затем перейти на уровень выполнения запросов из языка программирования. В php для этого используется библиотека PDO. И только затем переходить к ORM. Все это будет далее в курсах.
Вот лишь некоторые темы, вовлеченные в код выше:
- Entity-relation model
- Domain-driven design
- ActiveRecord/DataMapper
- Identity map/Unit of Work/Dirty
- Миграции
- Валидация
- Мета-программирование
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
