Любое программное обеспечение разрабатывается под конкретную предметную область, например:
- Система аналитики оперирует понятиями «просмотр», «сессия», «воронка» и «когорта»
- Для интернет-магазина понятия будут другими — «товар», «категория», «платежный шлюз».
Все вместе они составляют онтологию предметной области. В некоторых источниках встречается термин модель предметной области — это то же самое, что и онтология.
Кроме самих понятий онтология содержит и описание их связей. Например, сущность «Пользователь» связана с сущностью «Покупка» как «один ко многим». То есть один пользователь может выполнить сколько угодно покупок, но каждая покупка принадлежит только одному пользователю.
Модель предметной области — основа коммуникации и взаимопонимания между членами команды. Она не зависит ни от языка программирования, ни от программирования вообще.
Не важно, кто общается: программисты между собой или программисты с заказчиками, менеджерами или дизайнерами. Все вместе они оперируют сущностями и связями предметной области и бизнес-правилами, используемыми в данной программе. К таким правилам может относиться автоматическое включение скидки при заказе от определенного объема товаров:
Важно понимать, что модель отражает лишь часть предметной области с некоторой детализацией. Причем в программах от разных производителей модель может быть разной, даже если они из одной области. Конечно же, в некоторых областях есть некоторый набор фиксированных сущностей, их связей и правил работы — например, в бухгалтерии. Но есть и менее формальные области, в которых таких возможностей еще больше.
Приведем несколько примеров из Хекслета. Количество сущностей — больше сотни, количество связей — много сотен, количество правил посчитать сложно — их тоже много.
На основе модели предметной области формируется модель данных в коде. Создаем сущности, определяем их связи. Затем мы строим рабочий код, который оперирует сущностями, исходя из требований и бизнес-правил.
На этом этапе возникает вопрос: а как эти сущности будут отображаться на базу данных, в которой они хранятся?
Самый простой вариант — создавать по таблице на каждую сущность и связывать их через внешние ключи. В большинстве проектов именно так и делают. Для этого используют Object-relational mapper (ORM) — фреймворк для данных.
С помощью ORM описываются сущности и их связи, а также определяется то, как сущность отображается на базу данных (как правило, в полуавтоматическом режиме). ORM берет на себя серьезную часть работы по:
- Генерации SQL-запросов
- Извлечению данных
- Кастингу — преобразованию типов базы данных в типы целевого языка и обратно
- Автоматическому извлечению связей
В итоге получается, что ORM прячет всю работу с базой данных. От программиста нужна только правильная конфигурация, а ORM сам выполняет все необходимые запросы. В сложных случаях их все равно приходится писать самостоятельно, но это не так сложно — ORM содержат в себе query builder, который упрощает генерацию SQL.
В экосистеме Python есть несколько ORM. Некоторые из них разрабатывались под конкретные фреймворки и поставляются с ними, другие вполне самостоятельны. Рассмотрим пример, реализованный с использованием Django ORM.
Определение сущности Photo:
from django.db import models
class Photo(models.Model):
title = models.CharField(max_length=200)
image = models.ImageField()
slug = models.SlugField()
Использование:
# получаем объекты из базы
photos = Photo.objects.all()
# передаем их в шаблон
render(request, 'polls/detail.html', {'photos': photos})
Код, описывающий сущность, может показаться простым, однако степень автоматизации в Django ORM очень велика. Под капотом у такого простого кода скрыты создание сущности в БД и набор проверок значений, которые вы помещаете в модель.
Перед тем, как начинать работать с ORM, нужно сначала научиться основам баз данных. Причем не через программирование, а через прямую работу с базой. Также важно познакомиться с:
- Нормализацией
- Внешними и первичными ключами
- Индексами
- Планом запроса
- Языком SQL, чтобы менять структуры базы данных и манипулировать данными внутри базы
Затем можно перейти на уровень выполнения запросов из языка программирования. В Python для этого используются различные библиотеки вроде postgres. И только после всего этого стоит переходить к ORM. Все это будет далее в курсах.
Вот лишь некоторые темы, вовлеченные в код выше:
- Entity-relation model
- Domain-driven design
- ActiveRecord / DataMapper
- Identity map
- Миграции
- Валидация
- Метапрограммирование
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
