Урок 11. Основы ORM библиотеки Doctrine. События

Содержание материала:

ORM Doctrine

Первое, что делает мудрый человек, это спрашивает себя — зачем мне это нужно, вот и я решил поступить таким же образом, при знакомстве с ORM Doctrine (по факту реализующую спецификацию JPA).

Для начала я процитирую Википедию, потому что это базовые знания, без них никак.

Doctrine — объектно-реляционный проектор (ORM) для PHP, который базируется на слое абстракции доступа к БД (DBAL). Одной из ключевых возможностей Doctrine является запись запросов к БД на собственном объектно-ориентированном диалекте SQL, называемый DQL (Doctrine Query Language) и базирующийся на идеях HQL (Hibernate Query Language).

Преимущества

Существует несколько мнений, почему ORM значительно упрощает поддержку БД, например:

  1. удобно дебажить, когда переименовали или удалили поле «name» из таблицы — придется каким-то хитрым образом найти во всем проекте все места в коде, в которых запросы могут использовать это поле (в случае с ORM мы сможем поставить брейкопин на геттер и узнать, какой скрипт попытался выполнить неправильный запрос
  2. удобно переименовать поля — при использовании ORM можем воспользоваться всеми возможностями таких штук как Resharper, и автоматом переименовывать сразу во всем проекте (IDE позволяет находить все места использования поля)
  3. из коробки есть MasterSlaveConnection (конечно можно вручную можно разрулить проверяя substr(sql,0,6) == select, но зачем)
  4. Migrations Tools — инструмент управления версиями схемы бд
  5. можно переходить на другие БД — например можно перенести часть таблиц на NoSQL, и сделать это так, что ни один программист не заметит этого. По сути позволяет абстрагироваться от способа хранения объектов вообще, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (но такие манипуляии резко сокращают функционал работы с данными, например уже не получится сделать джоин таблиц из разных типов БД)
  6. можно настроить логирование и запросы в логах будут в виде SELECT * FROM product WHERE )
  7. Doctrine может возвращать объекты частично, целиком и даже умеет возвращать данные согласно указанному PDO Fetch Modes
  8. Doctrine умеет делать принудительную или ленивую загрузку связанных сущностей (объектов):

$query = $em ->createQuery(«SELECT s FROM ASBillingBundle:Subscription s»)->setFetchMode(
«ASBillingBundle:Subscription»,
«user»,
DoctrineORMMappingClassMetadata::FETCH_EAGER
);

  • а еще удобно писать сложные запросы с помощю построителя запросов ORM, например выборка товаров:
  • $select = $db->select()->from(‘goods’);
    $select->join(‘pages’, ‘pages. >
    if ($content) <
    $select->join(‘content’, ‘content. > $select->where(‘content. >getId());
    if ($search) <
    $select->where(‘content.contentName = ?’, $search);
    >
    >
    if (!$expired) <
    $select->where(‘goods.goodExpirationDate > ?’, time());
    >

    И давайте на чистоту — если Вы завтра решите добавить еще кое-какие поля в пару таблиц, немного поменять логику — вы легко измените ваши 38 написанных ручками запросов. Проблемы начинаются тогда, когда у вас в проекте полсотни-сотня таблиц со своими связями. Что вы сделаете в случае 462 «ручных» запросов? Правильно, вы запасетесь свободной неделькой, прошерстите все запросы, добавите/измените нужные, также поменяете обработчики данных для валидации, покопаетесь в формах, полезете в базу и добавите там все необходимое. Как следствие вы допустите массу ошибок и опечаток и еще неделю после будете отлавливать баги, из которых минимум пять все равно останутся незамеченными и всплывут уже в рабочем проекте в самое неподходящее время.

    Что вы сделаете в случае с ОРМ — Вы залезете в описание схемы, добавите нужные модели/свойства, перегенерируете все, получите на выходе измененные формы, модели и структуру БД, допишете немного кода, поправите отображение форм и пойдете пить пиво с друзьями.

    Закешируем какой-нибудь запрос

    Очистим кэш без рестарта приложения, в котором хранится кэш:

    php app/console doctrine:cache:clear-metadata
    php app/console doctrine:cache:clear-query
    php app/console doctrine:cache:clear-result

    Недостатки

    Недостатков фактически нет, но есть рекомендации, когда не стоит использовать ORM:

    1. когда Вам нужно вытащить из базы огромное количество данных, ведь создание объектов влечет расходы RAM и процессора
    2. когда вы работаете с огромным количеством запросов только на чтение, опять же, сэкономите на RAM и процессоре
    3. когда у Вас в проекте много аналитики, и нужно писать сложные SQL-запросы (делаете запросы через PDO и радуетесь приросту скорости)
    4. когда вам уже сейчас нужна полная поддержка всех фич базы, которая используется
    5. если не хотите слишком много времени тратить на изучение реализации нативных фич Вашей б.д. в ORM

    Решаемые проблемы

    1. все поля (которые foreign keys) при выборке данных, оказываются Proxy-объектами (можно побороть используя Hydration Modes или $object->getValue()->getFieldName() )
    2. при сохранении объектов, все поля с foreign key, должный быть объектами, т.е. нельзя явно указать user_id, значением должен быть именно объект User с заполненным значением свойства user_id ( говорят можно побороть так: EntityManager->getreference($class, $id) )

    Внутренности

    Коротко, паттерны из которых состоит:

    Data Mapper таблица базы данных может быть представлена как PHP-класс сущности, а строка из таблицы как экземпляр объекта класса
    Identity Map если ты повторно выбираешь ту же самую сущность из базы, тебе возвращается ссылка на существующую сущность. Доктрина следит чтобы каждая сущность существовала ровно в одном экземпляре, и это помогает избежать противоречий, когда есть несколько экземпляров одного объекта и непонятно в каком из них актуальные данные. Мартин Фаулер дает такое описание: Identity Map — гарантирует, что каждый объект будет загружен из базы данных только один раз, сохраняя загруженный объект в специальной коллекции. При получении запроса просматривает коллекцию в поисках нужного объекта.
    Unit of Work хранит в себе сведения обо всех объектах, извлеченных, обновленных, созданных и удаленных на протяжении текущего сеанса. Задача Unit of Work следить за всеми действиями приложения, которые могут изменить БД в рамках одной бизнес-транзакции. Когда бизнес-транзакция завершается, Unit of Work выявляет все изменения и вносит их в БД, параллельно оптимизируя этот процесс.
    EntityManager это классическая реализация паттерна Facade. Через его легкий API мы работаем с рядом подсистем: Unit Of Work, Query language и Repository API. Управление сущностями выполняется исключительно через API EntityManager-а. Например, когда ты делаешь изменения в сущностях, они не сохраняются автоматически, ты должен явно вызвать метод flush() и тогда произойдет следующее $this->unitOfWork->commit(); Таким образом Unit Of Work найдет все изменившиеся, новые и удаленные сущности и соответственно обновит/вставит/удалит записи в базе одной транзакцией.

    Для работы с разного типа базами данных используется Metadata Drivers

    Компоненты для работы с реляционными базами данных:

    Голубые блоки обозначают PHP-движок и расширения PHP, на основе которых построена Doctrine.

    Doctrine\Common. Общая библиотека для проектов Doctrine. Этот компонент предоставляет широко используемый набор функций.

    Doctrine\Annotations. Парсер многострочных комментариев.

    Doctrine\Inflector. Манипуляции со строками, касающиеся изменения регистра и единственного/множественного числа.

    Doctrine\Lexer. Базовая библиотека для лексического анализатора, который может использоваться в нисходящем синтаксическом анализе и методе рекурсивного спуска.

    Doctrine\Cache. Библиотека для кэширования, предлагающая объектно-ориентированный API для многих бэкендов кеша.

    Doctrine\DBAL. Абстрактный уровень БД. This is a lightweight and thin runtime layer around a PDO-like API and a lot of additional, horizontal features like database schema introspection and manipulation through an object oriented API.

    Doctrine\Collections. Библиотека для абстракции коллекций.

    Doctrine\ORM. Компонент для объектно-реляционного отображения. Позволяет работать с моделями сущностей объектно-ориентированным методом вместо запросов на чистом SQL.

    Doctrine\Migrations. Миграции схем БД с использованием Doctrine DBAL. Предоставляет последовательный способ управления схемой БД и ее обновления.

    Doctrine\DataFixtures. Данные предварительной настройки для всех менеджеров объектов Doctrine. Предоставляет фреймворк для создания данных предварительной настройки.

    Компоненты для работы с NoSQL-БД:

    Doctrine\MongoDB — уровень абстракции Dotrine MongoDB.

    Doctrine\MongodbODM (Object Document Mapper) предоставляет возможность устанавливать соответствие между документами NoSQL и моделями сущностей PHP.

    Doctrine\MongoODMModule — модуль Zend Framework 3, обеспечивающий функциональность Doctrine MongoDB ODM.

    Doctrine\CouchDB — компонент, предоставляющий API, который является оберткой для API CouchDB для доступа по HTTP.

    Doctrine\CouchDB — компонент CouchDB Document Object Mapper. Аналогично Doctrine ORM он предоставляет возможность доступа к БД объектно-ориентированным методом.

    Doctrine\OrientdbODM — набор библиотек PHP для использования OrientDB.

    Doctrine\PhpcrODM — это Object Document Mapper для PHPCR.

    Базы данных и Doctrine ORM¶

    Symfony не предоставляет компонента для работы с БД, но предоставляет тесную интеграцию со сторонней библиотекой под названием Doctrine.

    Эта статья полностью описывает использование Doctrine ORM. сли вы предпочитаете использовать чистые запросы БД, см. статью «How to Use Doctrine DBAL«.

    Вы также можете сохранять данные в MongoDB, используя библиотеку Doctrine ODM. См. документацию «DoctrineMongoDBBundle».

    Установка Doctrine¶

    Для начала, установите Doctrine, а также MakerBundle, который поможет сгенерировать код:

    Конфигурация базы данных¶

    Информация соединения БД хранится в виде переменной окружения под названием DATABASE_URL . Для разработки вы можете найти и настроить её внутри .env :

    Если имя пользователя, пароль или имя БД содержат любой символ, считающийся особенным в URI (например, ! , @ , $ , # ), то вы должны зашифровать его. См. RFC 3986, чтобы увидеть весь перечень зарезервированных символов, или используйте функцию urlencode для их шифрования.

    Теперь, когда ваши параметры соединения установлены, Doctrine может создать для вас БД db_name :

    Существует больше опций в config/packages/doctrine.yaml , которые вы можете сконфигурировать, включая вашу server_version (например, 5.7, если вы используете MySQL 5.7), которые могут повлиять на то, как функционирует Doctrine.

    Существует множество других команд Doctrine. Запустите php bin/console list doctrine , чтобы увидеть полный список.

    Создание класса сущности (Entity)¶

    Предположим, что вы создаёте приложение, в котором необходимо отображать товары. Даже не задумываясь о Doctrine или базах данных, вы уже знаете, что вам необходим объект Product , чтобы представить эти товары. Используйте команду make:entity , чтобы создать этот класс:

    Теперь у вас есть новый файл src/Entity/Product.php :

    Топ-пост этого месяца:  Мюллер впервые посоветовал вебмастеру закрыть свой сайт

    Этот класс называется «сущность», И вскоре вы сможете сохранять и запрашивать объекты Product в таблице product в вашей базе данных.

    Отображение большего количества полей / колонок¶

    Каждое свойство в сущности Product может быть связано с колонкой в таблице product . Добавляя конфигурацию отображения, Doctrine сможет сохранять объект Товар в таблицу product и запрашивать их таблицы product и превращать эти данные в объекты Product :

    Давайте дадим классу сущности Product ещё три свойства и свяжем их с колоками в БД. Это обычно делается с помощью аннотаций:

    • Annotations

    Doctrine поддерживает широкий спектр различных типов полей, каждый с собственными опциями. Чтобы увидеть полный перечень типов и опций, см. документацию типов отображения Doctrine. Если вы хотите использовать XML вместо аннотаций, добавьте type: xml и dir: ‘%kernel.project_dir%/config/doctrine’ в отображения сущностей в вашем файле config/packages/doctrine.yaml .

    Будьте осторожны, чтобы не использовать зарезервированные ключевые слова SQL в качестве названий колонок вашей таблицы (например, GROUP или USER ). См. документацию зарезериврованных ключевых слов SQL Doctrine, чтобы узнать детали о том, как их избежать. Или, сконфигурируйте имя таблицы с @ORM\Table(name=»groups») над классом, или сконфигурируйте названия колонок с опцией name=»group_name» .

    Миграции: Создание таблиц / схемы базы данных¶

    Класс Product полностью сконфигурирован и готов к сохранению таблицы product . Конечно, ваша БД на самом деле ещё не имеет таблицы product . Чтобы добавить её, вы можете использовать DoctrineMigrationsBundle, который уже установлен:

    Если всё сработало, то вы должны увидеть что-то вроде:

    Если вы откроете этот файл, то увидите, что он содержит SQL, необходимый для обновленя вашей БД! Чтобы запустить этот SQL, выполните ваши миграции:

    Эта команда выполняет все файлы миграции, которые ещё не были запущены в вашей БД.

    Миграции и добавление полей¶

    Но что, если вам нужно добавить новое свойство поля в Product , например, description ?

    Новое свойство отображено, но ещё не существует в таблице product . Не проблема! Просто сгенерируйте миграцию:

    В этот раз, SQL в сгенерированном файле будет выглядеть так:

    Система миграции умна. Она сравнивает все ваши сущности с текущим состоянием БД и генерирует необходимый для их синхронизации SQL! Как и раньше, выполните ваши миграции:

    Это выполнит только один новый файл миграции, так как DoctrineMigrationsBundle знает, что первая миграция уже была выполнена ранее. За кулисами, она автоматически управляет таблицей migration_versions , чтобы следить за этим.

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

    Создание геттеров и сеттеров¶

    Doctrine теперь знает, как сохранять объект Product в БД. Но сам класс ещё бесполезен. Все свойства — private , поэтому увидеть данные в них невозможно!

    По этой причине, вам нужно создать публичные геттеры и сеттеры для всех полей, которые вам нужно изменить снаружи класса. Если вы используете IDE вроде PhpStorm, то он может сгенерировать их за вас. В PhpStorm, поместите ваш курсор где-либо в классе, а потом перейдите в Код -> Сгенерировать меню и выберите «Геттеры и сеттеры»:

    Обычано вам не нужен метод setId() : Doctrine установит его за вас автоматически.

    Сохранение объектов в базе данных¶

    Пора сохранить объект Product в базе данных! Давайте создадим новый контроллер для экспериментов:

    Внутри контроллера, вы можете создать новый объект Product , установить данные в нём и сохранить его!:

    Поздравляем! Вы только что создали ваш первый ряд в таблице product . Чтобы доказать это, вы можете запросить БД напрямую:

    Рассмотрите предыдущий пример более детально:

    • Строчка 16 Метод $this->getDoctrine()->getManager() получает объект Doctrine менеджер сущностей (entity manager), который является самым важным объектом Doctrine. Он отвечает за сохранение в базу данных, и получение объектов из базы данных.
    • Строxки 18-21 В этой части вы создаёте объект $product и работаете с ним, как и с любым другим обычным PHP-объектом.
    • Строчка 24 Вызов persist($product) сообщает Doctrine, чтобы он «управлял» объектом $product . Это не создает запрос в базу данных.
    • Строка 27 Когда вызывается метод flush() , Doctrine просматривает все объекты, которыми он управляет, чтобы узнать, нужно ли их сохранять в базу данных. В этом примере, объект $product не существует в базе данных, так что менеджер сущностей выполняет запрос INSERT , создавая новую строку в таблице product .

    Если вызов flush() не удается, то вызывается исключение Doctrine\ORM\ORMException . См. Транзакции и параллелизм (Concurrency).

    Процесс одинаков и для создания, и для обновления объектов, рабочий процесс всегда одинаков: Doctrine достаточно умна для того, чтобы знать, стоит ей INSERT или UPDATE вашу сущность.

    Извлечение объектов из базы данных¶

    Извлечение объекта обратно из БД ещё проще. Представьте, что вы хотите перейти в /product/1 , чтобы увидеть ваш новый товар:

    12. Управление базой данных с помощью ORM Doctrine

    Doctrine — это PHP-библиотека с открытым исходным кодом, предоставляющая удобные методы для управления базой данных объектно-ориентированным способом. Для работы с реляционными БД Doctrine предоставляет компонент, который называется Object Relational Mapper — ORM. С помощью ORM таблице базы данных ставится в соответствие PHP-класс (с точки зрения DDD — предметно-ориентированного проектирования — он также называется классом сущности), а строке этой таблицы — экземпляр класса сущности. Если вы еще не знакомы с Doctrine, рекомендуем также обратиться к Приложению Г. Введение в Doctrine за вводной информацией об архитектуре этой библиотеки.

    Doctrine не является частью Zend Framework 3, это сторонняя библиотека. Мы рассматриваем ее в этой книге, потому что она предоставляет легкий способ добавления поддержки базы данных в веб-приложение на базе ZF3.

    Компоненты, рассматриваемые в данной главе:

    Doctrine ORM Лучшие практики?

    Здравствуй, уважаемое сообщество !

    Это не столько конкретный вопрос, сколько призыв к коллективному разуму . Многие из вас работали с Doctrine ORM и написали множество прекрасных проектов. И в ходе работы вы сталкивались с подводными камнями, типичными задачами и решениями, которымми возможно, могли бы поделиться с остальными. Ради чистоты и лаконичности кода, а так же архитектурных решений, которые ускорят разработку, давайте поделимся опытом. Возможно вам получалось создавать решения, которые были успешны (в рамках Doctrine ORM), возможно были те, которые загоняли вас в тупик.
    В интернете можно найти множество best practices примеров, которые работают в рамках одной entity, но абсолютно бесполезны в реальных проектах.

    От себя приведу несколько примеров:
    Хорошей практикой, как я считаю, является отделение репозиториев самой доктрины, и наших репозиториев. Для работы внутри вашей бизнес логики используйте собственные классы\сервисы репозиториев, которые обязательно имплементируйте от интерфейсов.
    Правила валидации для сущностей, а так же маппинг выносите в отдельные YML файлы, а не в аннотации. Это конечно спорный момент, кому что удобно, но я предпочитаю, чтобы мои сущности не зависели от ORM,
    Используйтие flush с параметром, если собираетесь совершить действие только над конкретной сущностью.
    Не бойтесь конструктора, прописывайте в нем зависимости вашей сущности, это сделает код более безопасным и позволит избавиться от некоторых сеттеров.
    Будьте внимательны касательно новой типизации в php7 и интерфейсов, если вы создаете интерфейс для сущности и прописываете в нем возвращаемые типы, а так как же задаете скалярные типы аргументов, то после генерации Доктриной Proxy-обьектов вы получите ошибку о несоответствии класса интерфейсу. (говорят будет поправлено в 2.6 версии)

    Урок 11. Основы ORM библиотеки Doctrine. События

    Doctrine — это очень популярный, функциональный и довольно гибкий представитель библиотек, которые реализуют объектно-реляционное отображение баз данных. Библиотеки подобного рода избавляют нас от рутины создания и выполнения SQL запросов, для манипуляции над информацией, хранящейся в базе данных. Это и делает их такими востребованными.

    Согласитесь, значительно проще и удобнее вызвать парочку методов — нежели вручную составлять SQL запрос, а потом выполнять его на сервере СУБД. Все современные фреймворки уже давно отказались от такого подхода и активно используют ORM библиотеки.

    Само по себе объектно-реляционное отображение хорошо тем, что представляет физическую таблицу базы данных в виде простого класса, свойства которого, по сути, являются полями таблицы, а методы — действиями, которые можно осуществлять над ее данными. И вы, как разработчики, в этом случае, работаете с объектом определенного класса, а не с таблицей в базе данных.

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

    Традиционно обучение в курсе построено «от простого к сложному», начиная с самых основ: установки библиотеки, конфигурации, выполнения запросов, реализации связей и т. д.

    После изучения данного курса вы научитесь использовать библиотеку Doctrine в собственных проектах для работы с базой данных — а именно, выбирать, добавлять, редактировать и удалять данные, организовывать связи, создавать собственные типы данных и многое другое.

    Урок 0. Основы ORM библиотеки Doctrine

    Урок 1. Основы ORM библиотеки Doctrine. Установка и первые шаги

    От автора: приветствую вас в первом уроке курса по основам библиотеки Doctrine ORM. Doctrine — это очень популярный, функциональный и довольно гибкий представитель библиотек, которые реализуют объектно-реляционное отображение баз данных.

    Библиотеки подобного рода избавляют от рутины создания и выполнения SQL запросов для манипуляции над информацией, хранящейся в базе данных. Это и делает их достаточно востребованными.

    Ведь согласитесь, значительно проще и удобнее вызвать парочку методов, нежели вручную составлять SQL запрос, а потом выполнять его на сервере СУБД. При этом все современные фреймворки уже давно отказались от такого подхода и активно используют ORM библиотеки.

    Само по себе объектно-реляционное отображение хорошо тем, что представляет физическую таблицу базы данных в виде простого класса, свойства которого, по сути, являются полями таблицы, а методы — действиями, которые можно осуществлять над ее данными. И вы, как разработчики, в этом случае работаете с объектом определенного класса, а не с таблицей в базе данных.

    В данном уроке мы рассмотрим с вами установку ORM библиотеки Doctrine в тестовый проект и опишем первую сущность — класс, представляющий реальную таблицу в базе данных. Также поговорим о мета-данных и создадим при помощи консоли таблицу, на основе тех данных, которые мы опишем в классе.

    Урок 2. Основы ORM библиотеки Doctrine. Мета-данные в виде XML и YML документов

    От автора: на прошлом уроке мы с вами описали первую сущность и поговорили о мета-данных, которые описывают структуру таблицы в базе данных. Мы использовали формат специальных комментариев непосредственно в описываемом классе. Помимо этого, указанную информацию можно добавлять отдельно в документы формата YML, XML, что, собственно, и рассмотрим в текущем уроке.

    Топ-пост этого месяца:  Центрирование с помощью Sass

    Также для закрепления пройденного материала, создадим несколько дополнительных таблиц и рассмотрим добавление информации в одну из них.

    Урок 1. Основы ORM библиотеки Doctrine. Установка и первые шаги

    Tamaño del vídeo:

    Mostrar controles del reproductor

    • Publicado el 13 dic 2020
    • Полный курс по библиотеке Doctrine тут:
      webformyself.com/category/premium/php-premium/doctrine-premium/
      Doctrine — это очень популярный, функциональный и довольно гибкий представитель библиотек, которые реализуют объектно-реляционное отображение баз данных.
      Библиотеки подобного рода избавляют от рутины создания и выполнения SQL запросов для манипуляции над информацией, хранящейся в базе данных. Это и делает их достаточно востребованными.
      Ведь согласитесь, значительно проще и удобнее вызвать парочку методов, нежели вручную составлять SQL запрос, а потом выполнять его на сервере СУБД. При этом все современные фреймворки уже давно отказались от такого подхода и активно используют ORM библиотеки.
      Само по себе объектно-реляционное отображение хорошо тем, что представляет физическую таблицу базы данных в виде простого класса, свойства которого, по сути, являются полями таблицы, а методы — действиями, которые можно осуществлять над ее данными. И вы, как разработчики, в этом случае работаете с объектом определенного класса, а не с таблицей в базе данных.
      В данном уроке мы рассмотрим с вами установку ORM библиотеки Doctrine в тестовый проект и опишем первую сущность — класс, представляющий реальную таблицу в базе данных. Также поговорим о мета-данных и создадим при помощи консоли таблицу, на основе тех данных, которые мы опишем в классе.

    Comentarios • 6

    Полный курс по библиотеке Doctrine тут:
    webformyself.com/category/premium/php-premium/doctrine-premium/

    про хелперы надо лучше рассказывать/объяснять .. не просто некий , а хоть немного подробней — что, почему, зачем

    я конечно не эксперт в обучении, но попытаюсь объяснить свою точку зрения:
    мне кажется сначала нужно показать преимущества технологии, смотрите мол раньше чтобы сделать вот так нужно была целая страничка кода, а сейчас всего лишь две строчки, хотите так научится, тогда начнем .
    а что вышло по факту, я начну учить а зачем вам это надо вы должны сами понять, за 43 минуты создан класс который сделает табличку и я все еще не понимаю в чем плюс технологии, ведь эту табличку можно было создать за 10-20 секунд в любом менеджере базы данных
    и эту ошибку делают очень многие учителя
    если и после второго урока не станет понятен плюс технологии то это будет epic

    Хот раньше я считал так же. Зачем весь этот оверхед, когда таблицу можно создать ща 20 сек. Вот люди идиоты которые пользуются всякими такими инструментами, которые не упрощают, а усложняют жизнь.. И писал весь пхп код в нотепад++ годами, пока не понял, насколько прекрасны ИДЕ. Так и запросы годами писал вручную, тратил годы своей жизни, пока не понял, зачем нужен ОРМ. Как по мне, пока человек сам на свои же грабли не наступит, он и не поймет)

    Ну я например стал искать про Орм и доктрин, когда уже наступил на грабли и понял, что это такое, писать огромное количество SQL запросов, что такое — создавать большие проекты на пхп, свой фреймворк и поработав в больших фирмах на более крутых языках програмирования с использованием крутых фреймворков. Думаю любому новичку будет сложно понять что такое объектно ориентированное программирование вообще, что такое слой ОРМ, что такое компосер, для чего все это нужно итд. Мне как программисту со стажем больше 10 лет смотрелось легко и интересно, разве что термины звучат смешно — доктрАйн, форсЕ, Нотация итд)))

    Урок 11. Основы ORM библиотеки Doctrine. События

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

    Это могло бы быть так же просто, как обновление поля updated_at каждый раз при изменении записи в базе данных, или отправка электронного письма каждый раз, когда в вашем приложении регистрируется новый пользователь.

    Doctrine 2 имеет систему событий, которая позволяет вам реализовывать события в рамках своего проекта.

    В этом уроке мы рассмотрим систему событий в Doctrine 2 и события жизненного цикла, к которым можно привязаться в рамках управления вашими сущностями.

    Что такое события?

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

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

    Вместо этого, каждый раз когда регистрируется новый пользователь, приветственное письмо может быть отправлено через систему событий. Это позволяет вам назначать для каждой части своего приложения одну функцию, а также позволяет легко (без внесения изменений в существующий код) добавлять и удалять то, что должно произойти после того, как событие имело место.

    Если вы хотите узнать больше о событиях и о том, как они реализуются с технической точки зрения, почитайте следующие две статьи из этой серии:

    • Using Events in Laravel 4 (Использование событий в Laravel 4)
    • Creating Registration Events in Laravel 4 (Создание событий регистрации в Laravel 4)

    Система событий в Doctrine

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

    • preRemove – событие preRemove сущности происходит до выполнения Менеджером сущностей соответствующей операции по удалению этой сущности. Оно не вызывается для оператора DQL DELETE.
    • postRemove – событие postRemove сущности происходит после удаления сущности. Оно активируется после операций базы данных по удалению. Оно не вызывается для оператора DQL DELETE.
    • prePersist – событие prePersis t сущности происходит до выполнения Менеджером сущностей соответствующей операции сохранения этой сущности. Следует иметь в виду, что это событие активируется только при первом сохранении объекта (т.е. оно не активируется при последующих обновлениях).
    • postPersist – событие postPersist сущности происходит после сохранения сущности. Оно активируется после операции базы данных по вставке. Первичные значения ключей доступны в событии postPersist .
    • preUpdate – событие preUpdate происходит до операций базы данных по обновлению данных сущности. Оно не вызывается для оператора DQL UPDATE.
    • postUpdate – событие postUpdate происходит после операций базы данных по обновлению данных сущности. Оно не вызывается для оператора DQL UPDATE.
    • postLoad – событие postLoad происходит после загрузки события в текущий Менеджер сущностей из базы данных или после применения к нему операции обновления (refresh operation).
    • loadClassMetadata – событие loadClassMetadata происходит после того, как отображаемые метаданные для класса загружены из источника отображений (аннотации/xml/yaml). Это событие не является обратным вызовом жизненного цикла.
    • preFlush – событие preFlush происходит в самом начале операции сброса (очистки).
    • onFlush – событие onFlush происходит после вычисления наборов изменений всех управляемых сущностей. Это событие не является обратным вызовом жизненного цикла.
    • postFlush – событие postFlush происходит в конце операции сброса (очистки). Это событие не является обратным вызовом жизненного цикла.
    • onClear – событие onClear происходит при вызове операции #clear(), после того как из единицы работы были удалены все ссылки на сущности.

    Примечание: Я взял эти описания прямиком из документации Doctrine .

    Вы можете привязаться к этим событиям двумя разными способами. Вы можете использовать либо обратные вызовы жизненного цикла для своих сущностей, либо слушателей событий жизненного цикла, которые являются специализированными объектами. Давайте посмотрим, как работать и с теми, и с другими.

    Методы обратного вызова жизненного цикла (Lifecycle Callbacks)

    Основной и самый простой способ привязки к событиям жизненного цикла это обратные вызовы жизненного цикла. Это методы, реализуемые на вашей сущности.

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

    Мы начнем с базового класса-сущности:

    Сначала нам нужно определить свойство класса $updatedAt :

    Затем мы определяем метод setUpdatedAt() , который задаст свойство для нового экземпляра DateTime :

    Теперь, теоретически, мы могли бы вызывать метод setUpdatedAt() в нашей кодовой базе каждый раз, когда хотели бы задать свойство $updateAt .

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

    Вместо этого мы можем сделать так, чтобы Doctrine автоматически вызывал метод при каждом обновлении этой сущности.

    Сначала добавьте к сущности следующую аннотацию:

    Затем добавьте следующую аннотацию к методу setUpdatedAt() :

    HasLifecycleCallbacks() уведомит Doctrine о том, что эта сущность должна перехватывать события обратного вызова. Если вы используете события обратного выбора, вам нужно иметь эту аннотацию только для вашей сущности.

    @ORM\PreUpdate говорит Doctrine автоматически вызывать этот метод при событии PreUpdate . Каждый раз, когда вы захотите обновить сущность User , столбец таблицы updated_at , соответствующий этой записи, будет задаваться автоматически! Неплохо, правда?

    Для часто используемого функционала (например, для поддержания свойств updated_at или created_at ) вместо реализации этого кода для каждой из ваших сущностей, лучше создать трейт, который вы просто включаете во все сущности, которые этого требуют.

    Есть вариант даже получше: если вы используете пакет Doctrine 2 for Laravel от Митчелла ван Вингаардена, вы можете воспользоваться уже готовым трейтом Timestamps.

    Слушатели событий жизненного цикла (Lifecycle Event Listeners)

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

    Но вместе с тем, обратные вызовы жизненного цикла могут раздуть ваши классы-сущности за счет дополнительных методов, которым, на самом деле, там не место.

    В вышеприведенном примере использование setUpdatedAt() для задания свойства $updateAt обоснованно, поскольку вы лишь автоматически задаете свойство для сущности.

    А что если вы захотите отправить электронное письмо? Мы ведь определенно не хотим сочетать нашу сущность со способностью отправлять электронные письма!

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

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

    В Doctrine предусмотрены два способа реализации этой функции – при помощи Слушателя или Подписчика.

    Топ-пост этого месяца:  Тестирование рекомендованных запросов с Google Chrome

    Использование Слушателя выглядит следующим образом:

    Затем вы регистрируете событие при помощи менеджера событий Doctrine:

    Или же вы можете создать Подписчика событий:

    Затем вы зарегистрируете Подписчика событий:

    Как видите, Подписчик событий реализует интерфейс EventSubscriber и имеет getSubscribedEvents() , который возвращает массив событий, на которые необходимо подписаться. В этом его отличие от Слушателя событий – там вы подписываетесь на события, когда регистрируете слушателя в менеджере событий.

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

    Теперь, когда у нас есть класс для работы с логикой события, мы можем внедрить зависимости в класс для последующей отправки электронного письма:

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

    Затем мы можем написать логику, чтобы отправить электронное письмо в методе postPersist() :

    Сначала мы можем получить Менеджера сущностей и экземлпяр сущности из LifecycleEventArgs , введенного как аргумент.

    Затем мы можем отправить электронное письмо при помощи объекта Mailer , введенного как зависимость:

    Однако Подписчик событий будет активироваться для каждой сущности, сохраняемой Doctrine. Это означает, что если мы бы только захотели отправить электронные письма новым сущностям User , нам нужно бы было включать if () в качестве оператора:

    Если вы хотите отправить приветственные письма множеству разных типов сущностей, вы можете указать подсказку для интерфейса:

    Если вы используете Слушателя событий или Подписчика для обновления свойств сущности, то это немного усложняет дело:

    Для этого нам нужно взять экземпляр UnitOfWork из Doctrine. UnitOfWork это то, как менеджер сущностей обрабатывает изменения, вносимые в ваши сущности.

    По сути, мы словно сообщаем Doctrine , что экземпляр, который на данный момент хранится в менеджере сущностей, нужно заменить на экземпляр, вводимый с обновленными свойствами.

    Unit Of Work представляет собой огромное преимущество Doctrine. Я не буду вдаваться в технические подробности работы Unit Of Work , потому что это не тема этой статьи и, к тому же, выше моего понимания. Я уверен, что мы разберем, как работает Unit Of Work, в одной из будущих статей.

    Заключение

    Doctrine имеет очень хорошую систему событий, которая позволяет вам с легкостью привязываться и выполнять определенные действия при наступлении определенных событий базы данных.
    Однако события Doctrine будут активироваться для всех сущностей в вашем проекте. Это и хорошо, и плохо.

    Это хорошо, потому что так легче поддерживать свойства сущностей (такие , как updated_at или created_at ) для всех ваших сущностей. Мы можете с легкостью создать трейт, и все ваши сущности автоматически примут этот функционал.

    Но я не считаю, что события Doctrine подходят для активации электронных писем или каких-либо других действий, не относящихся к базе данных. Как можно видеть из вышеприведенного примера, вводить подсказки для определенных сущностей может оказаться не так-то просто.

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

    Урок 1. Основы ORM библиотеки Doctrine. Установка и первые шаги

    ความคิดเห็น • 6

    Полный курс по библиотеке Doctrine тут:
    webformyself.com/category/premium/php-premium/doctrine-premium/

    про хелперы надо лучше рассказывать/объяснять .. не просто некий , а хоть немного подробней — что, почему, зачем

    я конечно не эксперт в обучении, но попытаюсь объяснить свою точку зрения:
    мне кажется сначала нужно показать преимущества технологии, смотрите мол раньше чтобы сделать вот так нужно была целая страничка кода, а сейчас всего лишь две строчки, хотите так научится, тогда начнем .
    а что вышло по факту, я начну учить а зачем вам это надо вы должны сами понять, за 43 минуты создан класс который сделает табличку и я все еще не понимаю в чем плюс технологии, ведь эту табличку можно было создать за 10-20 секунд в любом менеджере базы данных
    и эту ошибку делают очень многие учителя
    если и после второго урока не станет понятен плюс технологии то это будет epic

    Хот раньше я считал так же. Зачем весь этот оверхед, когда таблицу можно создать ща 20 сек. Вот люди идиоты которые пользуются всякими такими инструментами, которые не упрощают, а усложняют жизнь.. И писал весь пхп код в нотепад++ годами, пока не понял, насколько прекрасны ИДЕ. Так и запросы годами писал вручную, тратил годы своей жизни, пока не понял, зачем нужен ОРМ. Как по мне, пока человек сам на свои же грабли не наступит, он и не поймет)

    Ну я например стал искать про Орм и доктрин, когда уже наступил на грабли и понял, что это такое, писать огромное количество SQL запросов, что такое — создавать большие проекты на пхп, свой фреймворк и поработав в больших фирмах на более крутых языках програмирования с использованием крутых фреймворков. Думаю любому новичку будет сложно понять что такое объектно ориентированное программирование вообще, что такое слой ОРМ, что такое компосер, для чего все это нужно итд. Мне как программисту со стажем больше 10 лет смотрелось легко и интересно, разве что термины звучат смешно — доктрАйн, форсЕ, Нотация итд)))

    Урок 1. Основы ORM библиотеки Doctrine. Установка и первые шаги

    Tamaño del vídeo:

    Mostrar controles del reproductor

    • Publicado el 13 dic 2020
    • Полный курс по библиотеке Doctrine тут:
      webformyself.com/category/premium/php-premium/doctrine-premium/
      Doctrine — это очень популярный, функциональный и довольно гибкий представитель библиотек, которые реализуют объектно-реляционное отображение баз данных.
      Библиотеки подобного рода избавляют от рутины создания и выполнения SQL запросов для манипуляции над информацией, хранящейся в базе данных. Это и делает их достаточно востребованными.
      Ведь согласитесь, значительно проще и удобнее вызвать парочку методов, нежели вручную составлять SQL запрос, а потом выполнять его на сервере СУБД. При этом все современные фреймворки уже давно отказались от такого подхода и активно используют ORM библиотеки.
      Само по себе объектно-реляционное отображение хорошо тем, что представляет физическую таблицу базы данных в виде простого класса, свойства которого, по сути, являются полями таблицы, а методы — действиями, которые можно осуществлять над ее данными. И вы, как разработчики, в этом случае работаете с объектом определенного класса, а не с таблицей в базе данных.
      В данном уроке мы рассмотрим с вами установку ORM библиотеки Doctrine в тестовый проект и опишем первую сущность — класс, представляющий реальную таблицу в базе данных. Также поговорим о мета-данных и создадим при помощи консоли таблицу, на основе тех данных, которые мы опишем в классе.

    Comentarios • 6

    Полный курс по библиотеке Doctrine тут:
    webformyself.com/category/premium/php-premium/doctrine-premium/

    про хелперы надо лучше рассказывать/объяснять .. не просто некий , а хоть немного подробней — что, почему, зачем

    я конечно не эксперт в обучении, но попытаюсь объяснить свою точку зрения:
    мне кажется сначала нужно показать преимущества технологии, смотрите мол раньше чтобы сделать вот так нужно была целая страничка кода, а сейчас всего лишь две строчки, хотите так научится, тогда начнем .
    а что вышло по факту, я начну учить а зачем вам это надо вы должны сами понять, за 43 минуты создан класс который сделает табличку и я все еще не понимаю в чем плюс технологии, ведь эту табличку можно было создать за 10-20 секунд в любом менеджере базы данных
    и эту ошибку делают очень многие учителя
    если и после второго урока не станет понятен плюс технологии то это будет epic

    Хот раньше я считал так же. Зачем весь этот оверхед, когда таблицу можно создать ща 20 сек. Вот люди идиоты которые пользуются всякими такими инструментами, которые не упрощают, а усложняют жизнь.. И писал весь пхп код в нотепад++ годами, пока не понял, насколько прекрасны ИДЕ. Так и запросы годами писал вручную, тратил годы своей жизни, пока не понял, зачем нужен ОРМ. Как по мне, пока человек сам на свои же грабли не наступит, он и не поймет)

    Ну я например стал искать про Орм и доктрин, когда уже наступил на грабли и понял, что это такое, писать огромное количество SQL запросов, что такое — создавать большие проекты на пхп, свой фреймворк и поработав в больших фирмах на более крутых языках програмирования с использованием крутых фреймворков. Думаю любому новичку будет сложно понять что такое объектно ориентированное программирование вообще, что такое слой ОРМ, что такое компосер, для чего все это нужно итд. Мне как программисту со стажем больше 10 лет смотрелось легко и интересно, разве что термины звучат смешно — доктрАйн, форсЕ, Нотация итд)))

    Урок 11. Основы ORM библиотеки Doctrine. События

    Полный курс по библиотеке Doctrine тут:
    webformyself.com/category/premium/php-premium/doctrine-premium/

    Doctrine — это очень популярный, функциональный и довольно гибкий представитель библиотек, которые реализуют объектно-реляционное отображение баз данных. Библиотеки подобного рода избавляют нас от рутины создания и выполнения SQL запросов, для манипуляции над информацией, хранящейся в базе данных. Это и делает их такими востребованными.
    Согласитесь, значительно проще и удобнее вызвать парочку методов — нежели вручную составлять SQL запрос, а потом выполнять его на сервере СУБД. Все современные фреймворки уже давно отказались от такого подхода и активно используют ORM библиотеки.

    Само по себе объектно-реляционное отображение хорошо тем, что представляет физическую таблицу базы данных в виде простого класса, свойства которого, по сути, являются полями таблицы, а методы — действиями, которые можно осуществлять над ее данными. И вы, как разработчики, в этом случае, работаете с объектом определенного класса, а не с таблицей в базе данных.

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

    Традиционно обучение в курсе построено «от простого к сложному», начиная с самых основ: установки библиотеки, конфигурации, выполнения запросов, реализации связей и т. д.

    После изучения данного курса вы научитесь использовать библиотеку Doctrine в собственных проектах для работы с базой данных — а именно, выбирать, добавлять, редактировать и удалять данные, организовывать связи, создавать собственные типы данных и многое другое.

    Добавить комментарий