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

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

class CategoryRepository
{
    public function getAllCategories()
    {
        return Category::getAllCategories();
    }
}
Помогите разобраться
  • Вопрос задан
  • 744 просмотра
Пригласить эксперта
Ответы на вопрос 5
dmitriylanets
@dmitriylanets
веб-разработчик
Репозиторий это слои отделяющий приложение от хранилища, через этот слой проходят сущности (Entity) при сохранении, обновлении на входе и сущности и коллекции сущностей на выходе (Entity,Collection).
Репозитрии работают с драйвером бд и с маппером.
Именно на такой реализации я пока остановился
Ответ написан
Комментировать
Использование репозиториев является альтернативой ORM, то есть в этом случае модель Category не должна иметь методов получения или сохранения себя в БД.
Ваш пример будет выглядеть следующим образом:
class CategoryRepository
{
    /*
     * @return Category[]
    */
    public function getAllCategories()
    {
        // Извлекаем категории из БД и создаем массив моделей Category
        return $categories;
    }
}

Соответственно для сохранения категории ваш сервис должен иметь метод CategoryService::save(), в котором будут выполняться необходимые проверки и подготовка данных, а затем вызываться метод репозитория CategoryRepository::save(Category $category).
Ответ написан
Комментировать
Очевидно вопрос связан с современными фреймвоками типа Yii или Laravel. В них реализация упрощённая и смешанная. Совсем не DDD.

Классические модели из DDD ничего не знают о хранении и получении "объектов". Репозитории поставляющие "объекты" для модели и сохраняющие их никакого не имеют отношения к модели. Они из окружения приложения. Описываются через интерфейсы.
Ответ написан
Комментировать
gaparchi
@gaparchi
Почитай. Применение DDD и шаблонов проектирования. Джимми Нильсон. Там найдешь ответы.
Ответ написан
Комментировать
AlexanderByndyu
@AlexanderByndyu
IT-архитектор, эксперт в Agile&Lean
Я рекомендую использовать Dapper и шаблон QueryObject blog.byndyu.ru/2013/03/dapper-queryobject-orm.html

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы