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

P.S.: плюс данные могут браться и не из нашего хранилища, а запрашиваться со сторонних сервисов (наших партнёров, публичных и т.п.).Речь идёт о реализации логики к одной SQL базе. Понятно, что если баз много или они не-SQL, IQueryable тут вряд ли пригодится.Бизнес имеет тенденцию расширяться, если он конечно успешный. Сегодня база одна, а завтра...

Наверняка многие, кто пользуется вашими сервисами, имеют при этом свою локальную SQL базу.

Алексей КskyANAИ кстати люди постоянно забывают, что репозиторий призван скрыть от нас то, как распредены данные.Если мы готовы к "N+1", можно и скрыть. Всё зависит от задачи.Вы определение репозитория забыли, или Вы с ним не согласны?

Алексей КhVosttпропущено...


они просто говорят о репозитории, который является и в то же время моделью. модель (в понимании MVC), даже близко не является репозиторием, она его использует. это видимо и есть N+1 в вашем понимании.Я о том, что такой подход приведёт к необходимости множества методов типа GetMyEntityByID(int id) , что в свою очередь приведёт к N+1. IQueryable избавляет от этой напасти.Не приведёт.

hVosttskyANAпропущено...
Не приведёт.

вы с МСУ похоже не догоняете о чем говорит Алексей...Объясни своими словами.

Just UserПрошу помощи.
Начал разбираться с репозитариями... На сайте вроде всё красиво описывают, но в реале у меня не работает.
Подскажите ,что делаю не так.
Имеется база данных на SQLExpress.
1. В проект добавил edmx сформировав его на основе базы данных.
2. Описал абстрактный интерфейс
3. Написал реализацию репозитария:



В результате выдаёт ошибку:авторНевозможно завершить операцию, поскольку класс DbContext был удален.
Подскажите, что я не понимаю.
Из-за выделенной в коде контроллера конструкции в момент реального запроса к данным "класс DbContext удален".

hVosttskyANAпропущено...
Объясни своими словами.

представьте себе ситуацию, что никакого LINQ вообще нет. что тогда? вы будете делать нечто подобное, чтобы упростить ситуацию. придумаете свой сервис, чтобы генерить SQL код, чтобы не писать его вручную. объявите стандартный интерфейс типа GetById, GetAll... и т.д. короче сделаете свой репозиторий.

при наличии LINQ и необходимых провайдеров этого делать не нужно. по сути дата контекст -- это и есть репозиторий.

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

это и есть репозиторий. IQueryable<T> с этой задачей прекрасно справляется.

а теперь всякие IsDeleted, IsActive и прочая хрень, это уже бизнес-логика. для хранилища (базы данных) удаленный объект, -- это его отсутствие. запись с флагом IsDeleted -- это такая же запись, как и все остальные. хранилищу вообще по барабану на все эти флаги, условия, уровни пользовательского доступа приложения.

так вот это уже бизнес-логика. и никоим образом не имеет отношения к репозиторию. а вы эту логику с умным видом навешиваете на репу. репа это как раз то самое, что надо "крутить как хочешь".

в прикладной уровень выдайте сервис, который уже отдает IEnumerable и IList. а репу не трожьте.И тут Остапа понесло. Чтоб тебя завтра на Java заставили писать.

А если серъёзно, то ты глупости сейчас выдумываешь.

hVosttskyANAИ тут Остапа понесло. Чтоб тебя завтра на Java заставили писать.

А если серъёзно, то ты глупости сейчас выдумываешь.

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

однако. просто так он тебе ничего не отдаст. и просто так ничего не примет. только по накладной.

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

однако, машина которая приезжает от клиента, может вмещать определенное количетство товаров. и в случае чего приедет еще столько раз сколько нужно. в этом случае она работает со складом, однако опять же, по накладным, считай что с сервисом.

неужели непонятно?

репозиторий -- это абстракция над реальным хранилищем.

к примеру, дата контекст напрямую крутить не имеет смысла, так как -- прямая зависимость от EF / MS SQL. но если дата контекст будет реализовывать внешний интерфейс репозитория, то проблема решена. подсовывай вместо дата контекста что угодно, хоть зампаленные в память коллекции классов. по барабану. лишь бы интерфейс был полностью реализован.

что самое простое в данном случае, это реализовать IQueryable<T>. и парочку Add/Update. управляются транзакции через UnitOfWork, который являясь отдельным интерфейсом, логически существует вообще в стороне.

на счет времени жизни. то здесь уже давно есть решение. управлять жизнью объектов нельзя с помощью примитивного using() -- это детский сад и даже не смешно. создается специальный логический контекст типа LifeScope, которым рулит DI контейнер.

а то высосали проблему из пальца. и теперь решают её дедовскими методами :)Ну и какую умную мысль ты этим хочешь донести?

Just UserskyANA,
А как правильно?Я не использую IQueryable вне репозитория и не использую EF. Это камрада hVostt лучше спросить

Но. Варианта два:
1. Поднимать DbContext в начале запроса, убивать в конце;
2. Поднимать контекст на время работы конкртеного метода репозитория:Just Userхотя если в репозитарии пишу что-нибудь так