skyANA1. Поднимать DbContext в начале запроса, убивать в конце;Чтобы избежать нежелательных распределённых транзакций и иметь возможность возвращать из методов IQueryable, временем жизни контекста лучше управлять через ThreadStatic + счётчик ссылок.

skyANAЕсли доступ к данным содержит только методы вроде GetXXXByID, то возможноть "Client objects construct query specifications declaratively and submit them to Repository for satisfaction" не реализована.

System.LINQ.Expression == query specifications

следовательно:

DbContext == Repository

Все эти определения появились до появления LINQ2SQL. С его выходом всё поменялось. Просто не все ещё это заметили. :-)

Если кому-то в проекте требуется репозитарий поверх репозитария - я не против. Но мне это не надо. :-)

skyANAТо есть репозиторий тупо не предоставляет тот функционал, что должен (мог бы) предоставлять исходя из определения.Зачем реализовывать самому функционал, имеющийся в LINQ2SQL? Велосипедостроение тоже должно иметь разумные пределы. :-)

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


System.LINQ.Expression == query specifications

следовательно:

DbContext == Repository

Все эти определения появились до появления LINQ2SQL. С его выходом всё поменялось. Просто не все ещё это заметили. :-)
Вот так просто взял и нарушил концепцию Persistence Ignorance.RepositoryConceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.
Вроде тоже правильно:
авторConceptually, a Repository LINQ DbContext encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.

skyANAАлексей КЕсли кому-то в проекте требуется репозитарий поверх репозитария - я не против. Но мне это не надо. :-)Кому-то требуется полноценный репозиторий
Алексей Кпропущено...
Зачем реализовывать самому функционал, имеющийся в LINQ2SQL? Велосипедостроение тоже должно иметь разумные пределы. :-)Затем, что на прошлой работе данные о забранированном туре были распределены между основным хранилищем системы и конечными точками: поставщиками отелей, перелётов, трансфер, экскурсий и т.п. Интерфейс к основному хранилищу и конечным точкам был единый, а вот реализации разные. И как-то сложно было применять LINQ2SQL к данным в формате XML даже тогда, когда перешли с .Net 2.0 на .Net 3.5.

Затем что на текущей работе два хранилища: MS SQL Server и MongoDB, - и MS что-то пока не реализовала EF под MongoDB. А кэшируются они в memcached, что является key-value хранилищем, к которому писать IQueryProvider как-то глупо что-ли.Я уже пояснял, что рассматриваю случай с одной SQL БД. Если баз много - там всё очевидно, обсуждать нечего.

skyANAАлексей КЯ уже пояснял, что рассматриваю случай с одной SQL БД. Если баз много - там всё очевидно, обсуждать нечего.И что?И всё. :-)

skyANAРепозиторий должен обеспечивать работу с данными как с in-memory domain object collection, как бы последние не были распределены.В DbContext такой API присутствует.

skyANAТо что Вы при проектировании поддержку этого требования опустили из-за того, что у Вас случай с одной SQL БД, не даёт Вам оснований приравнивать DbContext к репозиторию. Не понял, где я чего опустил.

МСУАлексей КЯ уже пояснял, что рассматриваю случай с одной SQL БД. Если баз много - там всё очевидно, обсуждать нечего.
Слушай, ну бизнес так неоднороден и расплывчат, как можно закладываться только под БД? Ну а если сейчас БД, а завтра нужно через веб сервис протащить коллекцию из абаперской RFCFunction?А если завтра это будет не нужно? А оно медленно работает уже сегодня.

Зануды...

МСУАлексей КА оно медленно работает уже сегодня.
Ты о чем? Что в репозитории работает медленно? :)N+1

Мы ходим по кругу. :-)

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

МСУАлексей КN+1
Мы ходим по кругу. :-)
14913953 :) 14918949

skyANAА иногда полезно думать до и во время проектирования системы и смотреть, что вокруг-то происходит и пользоваться своим и чужим опытом, чтобы избежать лишних проблем.Главное - иметь своё мнение. И если оно отличается от мнения большинства, это ещё не значит, что оно неправильное. Ну да Бог с ней, с философией... :-)

Если по теме - хочется обсудить архитектуру, ориентированную на конкретную СУБД + EF + максимальная производительность. Повторюсь, обсуждать тривиальные вещи, которые нынче модно называть репозитарием, мне не интересно. Там всё очевидно.