репозиториев и запросы с помощью raw sql?
Я изо всех сил пытаюсь понять, как лучше всего запросить репозиторий.
Три фактора, которые сейчас вызывают у меня петлю:
- Тип возвращаемых данных
- Столбцы для выполнения запроса
- Количество возвращаемых записей
Точка 1
Что касается на первый вопрос:
У меня есть репозитории с множеством методов, которые возвращают комбинацию как сущностей, так и скалярных значений. Похоже, это ведет к «взрыву методов». Должен ли я всегда возвращать объект Entity? Как мне запрашивать объекты, в которых мне нужен только один столбец?
Пункт 2 Должен ли я при выполнении запроса включать каждый столбец в таблицу, даже если мне нужен только один или два столбца? Если я создам для этого специальные запросы, это приведет к появлению большего количества методов в репозитории
, пункт 3 Как мне предоставить условия для запроса? Я читал о спецификациях, но, как я понимаю, вы просматриваете возвращенные записи и отфильтровываете те, которые передаются в новую коллекцию. Это не кажется хорошей идеей с точки зрения производительности. Прямо сейчас я просто создаю новый метод в репо, например getNameById (), который инкапсулирует условие.
Обратите внимание на то, что я не использую ORM, у меня просто необработанный sql в моих репозиториях .
Обновление
Пункт 1: Основываясь на ответах и дополнительных исследованиях, будет ли это хорошей реализацией?
Прямо сейчас у меня есть большой репозиторий, который возвращает смесь скалярных объектов и объектов типа сущности (все те же объекты). Я думаю, что мог бы значительно уменьшить это, если бы просто использовал метод GetUser (userId) и забыл о написании методов, которые просто возвращают значения одного столбца.
Например, если мне нужно вернуть имя пользователя, я могу вызвать метод GetUser (userId), который гидратирует объект User, а затем на уровне сервиса просто отфильтровать его до имени пользователя.
Другой способ - использовать какой-то класс QueryBuilder, который я мог бы передать в репозиторий, который можно было бы проанализировать для создания правильного sql.
Точка 2
Оглядываясь назад, это очень похоже на точку 1, и моим текущим решением было бы просто захватить все поля таблицы. Это компромисс между производительностью и ремонтопригодностью.
Пункт 3
Мне нужно добавить какое-то предложение where. Я не уверен, имеет ли это смысл делать через спецификацию или просто строку sql. Мое текущее решение - создать новые методы для этих типов, но я бы хотел что-то более общее для Репозитория
В целом, я все еще исследую этот вопрос ... Я хотел бы услышать больше комментариев или ссылок на книги или ссылки такого рода связать все это воедино.