Всем привет, я Илья Сергунин, веб-разработчик из продуктовой команды Авито. Мы пишем на Go сервис для трейд-ин мобильных телефонов. На его примере покажу, как устроен наш менеджер транзакций.

Я регулярно вижу статьи в стиле "как использовать шаблон Репозиторий с Eloquent" (одна такая попала в недавний PHP-дайджест). Обычное содержание их: давайте создадим интерфейс PostRepositoryInterface, EloquentPostRepository класс, красиво их забиндим в контейнере зависимостей и будем использовать вместо стандартных элоквентовских методов save и find.

Зачем этот шаблон нужен иногда вовсе не пишут ("Это же шаблон! Разве не достаточно?"), иногда что-то пишут про возможную смену базы данных (очень частое явление в каждом проекте), а также про тестирование и моки-стабы. Пользу от введения такого шаблона в обычный Laravel проект в таких статьях сложно уловить.

Попробуем разобраться, что к чему? Шаблон Репозиторий позволяет абстрагироваться от конкретной системы хранения (которая у нас обычно представляет собой базу данных), предоставляя абстрактное понятие коллекции сущностей.

На прошлой неделе я написал статью о бесполезности шаблона Репозиторий для Eloquent сущностей, однако пообещал рассказать как можно частично его использовать с пользой. Для этого попробую проанализировать как обычно используют этот шаблон в проектах. Минимально необходимый набор методов для репозитория:

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);
}

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

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);

    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

Привет, Хабр! Какое-то время назад я заинтересовался фреймворком Hanami и, чтоб лучше отложилось в голове, начал переводить официальное руководство для новичков. Этим и хочу поделиться с сообществом. Переводить я старался ближе к оригиналу, но я более читатель, чем писатель и, если у вас будут замечания к переводу, не стесняйтесь их высказывать, я поправлю.

В этом руководстве мы создадим свой первый проект в Hanami, сделаем простое веб приложение. Мы коснемся всех основных компонентов фреймворка и покроем все написанное тестами.