Создаю я модель сложную - в этом участвуют несколько конструкторов. Коллеции ей заполняю, поля. Что лучше, создать один data context и передавать его вниз по конструкторам составляющих объектов, или в каждом конструторе свой контекст создавать?

Для простого примера, от балды накидал код:




Так вот, лучше так, как в коде, или лучше в самом верхнем по вызову конструкторе создать один раз и передавать через параметр в конструкторы ниже по иерархии вызовов?

Так в конструкторе класса С ошибка, но пофиг - главное, я про констекст спрашиваю.

Советуют поменьше давать жить контексту. Буквально, по контексту на транзакцию. Я желание есть, чтобы раз создать контекст при старте приложения и удалять его только при закрывании приложения.

Я вот что думаю. Если приложение работает с локальной БД, только для одного юзера, то можно, пожалуй, и один контекст на всё приложение шарить. А если много юзеров и серверная БД - уже чем меньше контекст живёт, тем лучше (тем меньше вероятность конкуренций и связанными с ней накладными расходами). Я правильно думаю?

Но вот в данном конрктеном случае, при каскаде инициализаций, достаточно же вроде одного контекста, который лучше передавать в параметрах конктрукторов?

skyANAЧто такое "модель сложная" и на фига ей какой-то контекст?
Я под этим подразумеваю, что её поля (модель - это класс) состоят из других типов, из коллекций этих типов и т. д. И при инициализации экземпляра модели сначала происходит инициализация экземпляров составляющих её типов, а затем её самой (это я назвал каскадной инициализацией). И каждый такой экземпляр инициализируется данными из БД. Эти данные берутся не прямо из БД, а череp энтитифреймворковское ORM, с которым я общаюсь через контекст данных (DBContext). Этот контекст - "типа БД", только в виде кода. Т. е. я работаю не с БД, а с контекстом. И вот я спрашиваю, один контекст создавать на такие каскадные инициализации (и, соответстввенно, передавать его в конструкторы составляющих типов), или создавать свои контексты по месту каждой конкретной инициализации?

skyANAuser7320пропущено...

Я под этим подразумеваю, что её поля (модель - это класс) состоят из других типов, из коллекций этих типов и т. д. И при инициализации экземпляра модели сначала происходит инициализация экземпляров составляющих её типов, а затем её самой (это я назвал каскадной инициализацией). И каждый такой экземпляр инициализируется данными из БД. Эти данные берутся не прямо из БД, а череp энтитифреймворковское ORM, с которым я общаюсь через контекст данных (DBContext). Этот контекст - "типа БД", только в виде кода. Т. е. я работаю не с БД, а с контекстом. И вот я спрашиваю, один контекст создавать на такие каскадные инициализации (и, соответстввенно, передавать его в конструкторы составляющих типов), или создавать свои контексты по месту каждой конкретной инициализации?Какой-то ActiveRecord на базе EF получается. ИМХО редко, кто сейчас так в .NET делает.
Почему ActiveRecord-то? У меня данные только считываются, но не обновляются (поэтому мне, кстати, лучше там выше, в коде, использоваться РидОнлиКоллекшн... ну да ладно). Я это, кстати, забыл упомянуть - не думал, что это важно.

Где-то в степиuser7320,
Имхо, тут все зависит от приложения, если данные получаются только для чтения, с натяжкой почему бы нет, будет работать и жить с экземпляром, но если подразумевается модификация данных в экземплярах классов, тут может возникнуть неразбериха
так как контекст это же и кеш первого уровня и замыкатель единицы работы ( грязный или чистый объект), имхо для этого дела
держать одни контекст а классы создавать через фабрику di/ioc, а концы контекста выкинуть через интерфейс типов создаваемых
или изолировать его через прокси методы.
Я тут репозиторий и единицу работы даже не это самое... не делаю. А данные да - только для чтения. Я просто формирую большую сложную модель, чтобы потом в представлении (ASP.NET MVC) раскидать её поля по разным местам.




Я вообще про сам принцип - в таком варианте, когда чтобы инициализировать класс, надо инициализировать сначала другие классы, которые от включает в себя в качестве полей, лучше пользоваться одним контекстом и передавать его по цепочке инициализаций, чем на каждом этапе инициализации создавать свой контекст? Это же кажется разумным? А если будет куча контекстов - во-первых, для чего? А во-вторых - даже если надо будет модификацию данных делать, то при многих контекстах внутри одного сложного объекта как раз и могут возникнуть всякие проблемы и неразберихи. Например, синхронизация одновременно существующих нескольких контекстов, каждый из которых содержит изменения своей части сложного объекта. Вот тогда-то и нужны единицы работы и репозиторий, а так-то, когда просто чтение - чего заморачиваться. Да?

skyANAuser7320 The primary class that is responsible for interacting with data as objects is System.Data.Entity.DbContext (often referred to as context). Разобрались?
А, кстати, да. Что-то забыл - там внизу рекомендации. Ну, как я и думал - нефиг для атомарных операций по контексту создавать - слишком жирно и не зачем. Собственно, создание такого сложного объекта, что я выше описал, и есть один запрос, после которого я отдаю через контроллер этот объект в представление и всё - контекст можно убивать.

Можно считать, что разобрался.

Тогда мой код выше должен выглядеть так:

skyANAuser7320, да для на фига тут вообще какие-то свои классы и контексты? Храните свой сложный объект в MongoDB и отдавайте как BsonDocument прямиком в представление.
Я кроме СКЛ Сервера ничего не знаю и пока (пока!) знать не хочу. У меня ещё голова не выросла, чтобы столько вмещать. Да и это не относится к теме вопроса - я же не спрашиваю, какая вообще СУБД лучше, а спрашиваю, какой вариант при имеющихся вводных лучше.

skyANAuser7320Да и это не относится к теме вопроса - я же не спрашиваю, какая вообще СУБД лучше, а спрашиваю, какой вариант при имеющихся вводных лучше.Изначально вводных почти и не было. Только теперь понятно, что это веб и только чтение.

Я бы использовал Dapper ( performance of SELECT mapping ), и уж точно бы не стал так жёстко связывать модель с DBContext.
Нет, это опять советы с выходом из обсуждаемой темы, с предложением сторонних средств. Я за производительностью сейчас не гонюсь. Вот Где-то в степи правильно начал говорить - по сути.


EDUARD SAPOTSKI,
вы так говорите, будто мой контекст уже содержит в себе все данные БД. На сколько я знаю, поначалу он вообще как бы пустой и содержит в себе в основном "схему БД" в терминах языка программирования (классы там и прочее). Думаю, даже если генерить такую схему, отображающую полсотни таблиц, на каждом чихе, затраты не будут большими. Если я не гонюсь за оптимизациями, то и так сойдёт. В конце концов, на первом месте стоит быстрота разработки и удобство поддержки и развития кода, а не сверхскорость его исполнения. Иначе я бы не выбрал .NET, а выбрал какой-нибудь С или С++.



Где-то в степи

автор1 тяжелая инициализация в конструкторе, гораздо прагматичней инициализация по требованию
А если я сделаю конструктор по-умолчанию без инициализаций и конструктор с параметром контекста БД, куда и буду передавать этот контекст, созданный раньше, вне конструктора (а, например, в коде, его, конструктор, вызывающем)?

автор2 куча запросов бомбит сервер имхо не осмысленно.
проще сделать наследование c:ZZ и вытащить все одним джойном,( ну тут надо смотреть структуру)
Ну, может, и можно вытащить. Только у меня модель не обязательно повторяет структуру связей в БД. Так что если и получится вытащить джойном, то не всё. Я так думаю. С другой стороны, опять же про "бомбить" - так ли уж важно, один раз джойном я обращусь к БД, или три раза простым запросом? Велика разница? Снова стоит учесть, что у меня не высоконагруженный сервис и я не гонюсь за производительностью в первую очередь.

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

EDUARD SAPOTSKIskyANAа Вы что под контекстом понимаете в своём посте выше?
Честно говоря так до конца и не понял что ТС имеет ввиду под контекстом, хоть и перечитал его пост три раза, в моем понимании контекст это набор бизнес-сущностей которыми оперирует приложение. Браться они могут из БД, из веб-сервисов, хоть из текстового файла, не суть...
Контекст - в терминах EF, как по ссылке было сказано. Т. е. класс, DBContext, экземпляры которого, собственно, и являются "как бы БД" для моего кода. Я его использую как репозиторий. По-моему, для простых проектов нормальный такой репозиторий. Во всяком случае, свой, находящийся по возможностям хотя бы близко к EF, я бы не написал.

авторА если я сделаю конструктор по-умолчанию без инициализаций и конструктор с параметром контекста БД, куда и буду передавать этот контекст, созданный раньше, вне конструктора (а, например, в коде, его, конструктор, вызывающем)?
Я хотел сказать, что если я сделаю как договорились и дочитались выше - создам контекст в начале запроса и буду его передавать всяким конструкторам, которым он нужен? Так и советуют в той статье про EF.