Куда писать sql запросы при реализации репозиториев (DDD)?

Question

[Kolya Vantukh]

Нужен совет по структуре репозиториев . В общем сейчас есть просто модели , допусим Category с методами примера GetAllCategories() и т.д , где находится sql код , ОРМ не используется . Хочу переделать свой проект на архитектуру controller-service-repository . с контроллерами и сервисами более менее понятно , а вот с репозиториями не совсем .
Писать sql код нужно прямо в методах репозиториях ? тогда получается , что у меня все модели станут репозиториями и сущностей как таких вообще не останется . или делать еще одну ненужную абстракцию поверх модели Category ? это тоже как-то не очень разумно .

class CategoryRepository
{
    public function getAllCategories()
    {
        return Category::getAllCategories();
    }
}

Помогите разобраться

Comments

[YaRobot]

SQL в DDD ?
Значит уже не полноценный DDD.
Запросы в репозиториях.

Модель, это объект который лежит в другом слое и не связан с репозиториями.
Модель не должна знать о приложении и его работе. Рядом с моделью, может находится интерфейс репозитория но не сам репозиторий.

[Kolya Vantukh]

YaRobot, то есть в репозиторий нужно инжектить модель(сущность) и по том в зависимости от запроса в репозитории вызывать методы сущности ?

[YaRobot]

Kolya Vantukh, Репозиторий (в вашем случае sql запросы), должен находится на уровне приложения.
Уровень домена (модели/интерфейсы/сущности), не должен иметь понятия о вашем приложении.

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

[YaRobot]

Kolya Vantukh, DDD это довольно спорная тема и каждый в последнее время пишет свою реализацию =)

Ранее было по классике.
Приложение содержит мапперы, контроллеры, репозитории, реквесты, респонсы и остальную мишуру.
Домен же содержит интерфейсы, модели, команды и хендлеры (с последними спорный вариант).

Answer 1

[dmitriy]

Репозиторий это слои отделяющий приложение от хранилища, через этот слой проходят сущности (Entity) при сохранении, обновлении на входе и сущности и коллекции сущностей на выходе (Entity,Collection).
Репозитрии работают с драйвером бд и с маппером.
Именно на такой реализации я пока остановился

Answer 2

[Игорь Русинов]

Использование репозиториев является альтернативой ORM, то есть в этом случае модель Category не должна иметь методов получения или сохранения себя в БД.
Ваш пример будет выглядеть следующим образом:

class CategoryRepository
{
    /*
     * @return Category[]
    */
    public function getAllCategories()
    {
        // Извлекаем категории из БД и создаем массив моделей Category
        return $categories;
    }
}

Соответственно для сохранения категории ваш сервис должен иметь метод CategoryService::save(), в котором будут выполняться необходимые проверки и подготовка данных, а затем вызываться метод репозитория CategoryRepository::save(Category $category).

Answer 3

[Евгений Педя]

Очевидно вопрос связан с современными фреймвоками типа Yii или Laravel. В них реализация упрощённая и смешанная. Совсем не DDD.

Классические модели из DDD ничего не знают о хранении и получении "объектов". Репозитории поставляющие "объекты" для модели и сохраняющие их никакого не имеют отношения к модели. Они из окружения приложения. Описываются через интерфейсы.

Answer 4

[gaparchi]

Почитай. Применение DDD и шаблонов проектирования. Джимми Нильсон. Там найдешь ответы.

Answer 5

[Александр Бындю]

Я рекомендую использовать Dapper и шаблон QueryObject blog.byndyu.ru/2013/03/dapper-queryobject-orm.html

Есть пример реализации инфраструктуры на таком подходе с CQRS https://github.com/Byndyusoft/Byndyusoft.Dotnet.Co...