test_taskможет даже не работать в зависимости от EF/NH

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

test_taskможно было бы перенести условие выборки до проекции в DТО. и там использовать спецификацию AccountByUserSpecification. и это работает в EF, проверял (какой там SQL я не смотрел), а в NH падает с "не поддерживается".

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


test_taskВы, hVostt , писали еще про фильтрацию. там еще больше будет различий реализаций EF/NH, особенно в части подзапросов. как вы с этим боретесь?

Мы решили вопрос по-другому, мы обходимся вообще без подзапросов. Вместо этого у нас плоские проекции данных в SQL и ElasticSearch, благодаря архитектуре CQRS / ES. А репозиторий у нас возвращает объекты только по ID, никаких списков, фильтров и прочего. Это не нужно совсем.

AntonariyТак она и решается на стыке. public AjaxJsonGetResult<Paging<UwsRoles>> GetPQList это метод контроллера.

Точно, не сразу понял, что это у тебя контроллер.

AntonariyhVosttПо моему же глубокому убеждение, методов, возвращающих коллекции репозиторий иметь не должен. Он должен уметь извлечь сущность из хранилища по ID, добавить и удалить. Всё.Тогда какой в нем смысл? Все это контекст умеет делать.

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

С DbCobtext-ом это решается через LINQ-проекции. Это довольно неплохой и эффективный способ получать данные быстро без накладных расходов. Автоматическая генерация SQL с подзапросами опять же. Но здесь есть предел гибкости. Кеширование приделать довольно трудоёмко и сложно (инвалидация), разнести данные по разным хранилищам практически никак.

Масштабируется такое решение совсем плохо. С микросервисной архитектурой такой подход не дружит совсем, в общем информационном пространстве, но с разными ограниченными контекстами.

ПарамонA уровнем выше тоже нет обертки в GetBy1() ?
Типа в контроллере будет repo.Find(someSpecification) ?

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

Часто, когда программистами создаётся кучу всяких слоёв: репозитории, дата-сервисы, uow, менеджеры, провайдеры и ещё +100500 интерфейсов... Это вообще никак не приводит к тому, чтобы в контроллерах не писалась бизнес-логика. Она всё равно там пишется, а ещё размазывается по классам. Только используя интерфейсы, чтобы.. ну типа связать всё в одно. Подобное легко обнаружить, глядя на конструктор контроллера: видишь там 5-10 зависимостей, сразу понимаешь ниже будет треш

skyANA,

Он просит показать спецификацию для условия "А найди мне проживание в Праге с 1-го по 14-е августа для двух взрослых и ребёнка до 12 лет в таком-то ценовом диапазоне".




Можно разбить на несколько спецификаций и смешивать их. Или сделать Строителя.

ПарамонЭто сложно понять из названия, оно слишком общее.

В контексте букинга, сложно придумать другой смысл :)