xxxTIMxxxКак правильно делатьОт приложения зависит. В большинстве случаев контейнеру указывают, чтобы создавал один экземпляр на поток, или запрос.

hVosttАлексей КИ таскаешь его параметром методов между сервисами.

Ето как?Это видимо какая-то своя реализация Unit of Work.

hVosttskyANAЭто видимо какая-то своя реализация Unit of Work.

Не понятно как ето таскать параметром методов.А я понял как, у нас в старом г-коде тоже много где встречается:




Мы это г. активно рефакторим.

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


Ето как?Если в разных методах понадобится один контекст.1. Для этого не обязательно его передавать в параметрах метода;
2. Ты кстати можешь оценить насколько часто может "понадобится один контекст в разных методах"?

Алексей КskyANAпропущено...
1. Для этого не обязательно его передавать в параметрах метода;Ну я и предложил вынести его на уровень класса и подсовывать снаружи диконтейнером.Через конструктор, свойство, как?
Алексей КskyANA2. Ты кстати можешь оценить насколько часто может "понадобится один контекст в разных методах"?У меня часто, у остальных - не знаю.больше 50%?

Алексей КskyANAпропущено...
Через конструктор, свойство, как?Конструктор, свойство - как больше нравится, как умеет диконтейнер.
skyANAпропущено...
больше 50%?Достаточно часто, чтобы не таскать в параметрах.Понятно, вообщем как у нас.

Алексей К, а зачем ты вообще это написал: 17362427 ?

hVosttАлексей КЗависит от архитектуры. Например, если это веб-приложение, то удобно привязывать время жизни сервисов и DbContext к http-запросу.

Но об этом уже было сказано.

А если не веб?К потоку.

hVosttАлексей Кпропущено...
К какому? При продолжении через I/O Completion Port потоков много.

Видимо имеется в виду основной поток приложения.

Пока не вижу смысла стыковаться к потоку. В зависимости от задачи, время жизни сервиса для выполнения некоего действия (бизнес-операции) должно быть сопоставимо с началом и окончанием этой операции.

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

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

Под контекстом имеется в виду не DbContext, а абстракция типа HttpContext-а, только для бизнес-операции, контекст создавался со своим life time scope, умервщлялся убийством scope вместе со всеми своими зависимостями. Сложная операция может порождать подконтексты по тому же принципу.

От большого контекста на поток отказался сразу. Всё, что жило в памяти, это кеш и оперативные данные (на самом деле просто живущие как синглетоны в контейнере).на примере StructureMap: http://docs.structuremap.net/Scoping.htm

Имелись в виду пункты 6 и 3.

hVosttприменялись те же принципы, что и в вебВ веб же какой основной принцип? Выполнил команду, закрой соединение и верни его в пул, т.к. в большинстве случаев все работают под одной учёткой, в одном application domain, в одном процессе.

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

hVosttskyANAпропущено...
В веб же какой основной принцип? Выполнил команду, закрой соединение и верни его в пул, т.к. в большинстве случаев все работают под одной учёткой, в одном application domain, в одном процессе.

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

А ещё есть мысли кроме идеи «десктоп это не веб»?Мысли насчёт чего? Вот ты ещё какие "принципы, что и в веб" можешь озвучить и на чём они основаны?

hVosttskyANAМысли насчёт чего? Вот ты ещё какие "принципы, что и в веб" можешь озвучить и на чём они основаны?

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

У десктопного приложения есть основной поток, и он является единственным основным потоком до момента закрытия приложения. Привязываемся к этому потоку? По сути это значит, делать контекст синглетоном, и всё тут. Или ты имел в виду что-то другое?Насчёт DbContext не скажу (с EF не работал), а вот держать открытое соединение (DbConnection) - это вполне себе нормально.

hVosttskyANAНасчёт DbContext не скажу (с EF не работал), а вот держать открытое соединение (DbConnection) - это вполне себе нормально.

Соединение это совсем другое. EF DbContext эт чистый UOW практически, исходя из этого я спрашивал, есть ли другие широко известные способы работы с ним.Хорошо, давай разбираться.

UoW нужен для того, чтобы отслеживать действия над объектами (создание, изменение, удаление) и выполнять соответсвующие запросы (INSERT, UPDATE, DELETE) во время Commit (или Flush, или что там в EF).

В ADO.NET он реализован где? Правильно, в DataSet. И вот тебе самый, что ни на есть "широко известные способы работы с ним" :)

Также UoW тесно связан с бизнес-транзакциями, это да. Но не обязательно одна бизнесс-транзакция == один объект, реализующий UoW.
На том же DataSet можно показать, что выполнили пачку каких-то действий, вызвали DataAdapter.Update(DataSet dataSet) и DataSet.AcceptChanges() .
И продолжаем работать дальше.

И в случае NHibernate сделали Flush и продолжаем работать дальше.
И в EF думаю можно также.

Ну и lifecycle сервиса != lifecycle UoW.

hVosttДопустим, открываем большую форму редактирования, для всей формы создаётся контекст, в рамках которого живут полученные сервисы. При сохранении выполняется пакетное сохранение данных контекста, при отмене контекст просто убивается и всё.Вот тут надо задуматься, а выполнит ли контейнер Release сразу при закрытии формы.

hVosttskyANAТакже UoW тесно связан с бизнес-транзакциями, это да. Но не обязательно одна бизнесс-транзакция == один объект, реализующий UoW.

Вообще-то говоря, желательно, так как в рамках одного объекта, реализующего UoW отслеживаются все изменения и взаимосвязи данных, коммит сохраняет полное состояние операции. Если объектов будет больше, теоретически может возникнуть несогласованное состояние.Я не верно выразился. Надо читать так: не обязательно одна бизнесс-транзакция == новый объект, реализующий UoW :)