Создаю я модель сложную - в этом участвуют несколько конструкторов. Коллеции ей заполняю, поля. Что лучше, создать один 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.

Кстати, я так понимаю, что тогда этот контекст надо создавать в методе контроллера, который вызывается пользователем, и затем передавать УЖЕ СОЗДАННЫЙ В КОНТРОЛЛЕРЕ контекст в модели (и дальше по иерархии моделей)? Да?

авторчто это? z => z.x == c.x
и прочее подобное.
Это и вообще почти все нагромождения в моём коде - чтобы просто показать, что я там что-то делаю, как-то выбираю данные и прочее. Основной вопрос - чего делать с контекстом БД в случае, когда много конструкторов одиз из другого вызываются.

авторОстается только добавить, что если приложение не сложное, то все это лишняя головная боль
Во-во. Если я напишу репозиторий и выложу свою поделку сюда, набегут критики, которые будут говорить, что конкуренции не обработаны, что нет защиты от дурака, что не предусмотрено аварийное отключение электроэнергии и пр. Уже обсуждали недавно в одной теме, где человек тоже про репозиторий спрашивал. Вроде, пришли в основном ко мнению, что либо делать хорошо, реализуя вот все эти хреновины с конкуренциями и пр., либо пользоваться ORM от EF как репозиторием напрямую.

автортяжелая инициализация в конструкторе, гораздо прагматичней инициализация по требованию
А, понял. Т. е. мне надо убрать все эти ToList() и просто пройтись тем же foreach'ем по IEnumerable (или IQuerable) в предсталении. Тогда непосредственно запрос из БД будет только на этапе создания представления, так?

авторВот только ТС что-то там развивать собрался и при подходе "а репозиторий мне пока не нужен и производительность мне не важна сейчас" велика вероятность наступить не на одни грабли.
Приложение, скорее всего, будут развивать. Только здесь и сейчас просят в сжатые сроки, в которые я им нормальный репозиторий не выдам. Значит, будут переписывать потом нормально.

Где-то в степиГде-то в степи,
конечно об этом говрить можно много, но с моей точки зрения, нужно поработать с базой, или денормализовать ее, накинуть связи
там в общем то тремя запросами не пахнет, там куда больше
Я тут подумал. Наверное, джойнами можно будет. БД нормальная, и связей там может даже больше, чем надо. Просто я с джойнами не очень дружу. Мне проще три простых запроса и потом из их результатов создать сложную модель. Ну, я посмотрю, что там у меня можно с джойнами сделать. Ещё раз говорю, что код, что я написал - от балды, лишь бы показать, что конструкторы не пустые и что-то делают.

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

Приложение, скорее всего, будут развивать. Только здесь и сейчас просят в сжатые сроки, в которые я им нормальный репозиторий не выдам. Значит, будут переписывать потом нормально.Вы только предупредите о такой вероятности тех, кто просит, чтобы они потом не удивлялись, что новые требования вызывают следующую реакцию: "Чёрт, это надо всё переписывать".
На этом всё серьёзное мировое ПО стоит. Я тут даже боюсь соваться со своими нововведениями. Лучше сделаю как все, пока сам крутым не стал и не получил значимость и мировую известность. Потом создам свой шаблон проектирования. Какой-нибудь "со мной переписывать некогда не надо".

Где-то в степиuser7320,
не нравится
1 тяжелая инициализация в конструкторе , гораздо прагматичней инициализация по требованию
2 куча запросов бомбит сервер имхо не осмысленно.
проще сделать наследование c:ZZ и вытащить все одним джойном,( ну тут надо смотреть структуру)
3 не желание применять фабрику и инжекции
Да и вообще все не нравится вплоть до названий полей и классов
Я уже понял, что вы имели ввиду. Уже сделал проще. Типа такого . Там строка

ur => new UseRecommendationModel()

и далее данные передаются там. А в UseRecommendationModel свой подзапрос может быть. В результате всё в пределах одного запроса и контекст БД никуда в конструкторы не передаётся.

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

На этом всё серьёзное мировое ПО стоит. Я тут даже боюсь соваться со своими нововведениями. Лучше сделаю как все, пока сам крутым не стал и не получил значимость и мировую известность. Потом создам свой шаблон проектирования. Какой-нибудь "со мной переписывать некогда не надо".Философию не учили?
Мне она никогда не нравилась.