Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
по поводу трехдневного срача по di оставив за бортом тему sl или di хочу ( и призываю вас подвести резюме) по поводу освобождения ресурсов через di. так как реализаций ди очень много порядка 180 - 200 штук в топе только порядка десятки, стоит рассмотреть это на примере Unity реализация укладывается в концепцию кеширование захваченного объекта, то есть реализована фитча для гурманов -, можно получать: объект как общий синглтон, как синглтон на период запроса, на период работы в потоке, или еще как ( еще как вы можете реализовать сами создав свою модель кеширования - управление жизнью объекта( ну например один для всего контекста формы)) Если вы захватили ссылку на объект в контейнере, то уж ничего не остается как при удалении контейнера удалять правильно объекты которые захватили ресурсы, вот пример синглтона для всей жизни рабочего контейнера, Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. то есть объект захвачен и при диспоузе контейнера, происходит освобождение ресурсов объекта ( если он наследует IDisposable) а вот дефолтное поведение, у которого нет этого счастья, при каждом запросе - создается новый объект, тут надежда на разработчика. Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Так стоит или не стоит рукоблудить, конечно стоит, работайте в своей парадигме как и раньше, Диспозьте по надобности, тут дело вот в чем: 1 сам паттерн допускает многократное повторение операции. 2 если не будете освобождать в ручную, освобождение ресурсов в контейнере происходит только когда вы отдиспозите сам контейнер, а этого события можно ждать очень долго - если предположить что один контейнер на форму.... чего стоит опасаться: 1 если объект захвачен контейнером, при повторном вызове уже освобожденного объекта - можно нарваться на инвалида. 2 если вы запустите объект куда нибудь за облака а потом его отдеспоузите через контейнер - то за облаками будет null. ну и про сам контейнер, не велика птица протаскивать его через конструктор, делаем закрытый от всех контейнер, а наружу выставляем IUnityContainer через CreateChildContainer(), т.е. контейнер дитя - контракт на одноразовую работу, потом по надобности прибиваем.. сам никогда этой штуковиной не пользовался - дополняйте.... Просьба не сильно с...ть, охотник по пятам, уже два топика накрыл... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 22:40 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Где-то в степит.е. контейнер дитя - контракт на одноразовую работу, потом по надобности прибиваем.. нормальный ход ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 22:53 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Не, я придерживаюсь идеологии статичности контейнера. Доступен на протяжении жизни апп домена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 22:57 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
МСУ, да пускай так будет, делаешь статический. регистрируешь типы, и от него получаешь детей для работы, а как ты хотел в статическом -одно на все приложение освобождать объекты которые захвачены - в конце приложения?, получается они все время жизни приложения там таскаться будут? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:04 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
МСУ, примерно так через nuget расширить можно Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:17 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Где-то в степи, не понял вопроса. В конце приложения будет выгрузка домена, можно даже не заморачиваться о диспоузе managed объектов. Во-вторых, статический контейнер вполне себе резолвит сервисы в соответствии с их заданными life time. То есть диспосабельные сервисы ты дестроишь сам по месту. В mvc я их дестрою автоматом в базовом контроллере, все сервисы там ленивые, разумеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:20 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
МСУ, да ради бога, если все в елочку, кто запрещает, тем более там все захваты монитором лочатся, но очевидный путь для меня через детей, тем более при желании можно исполнять с ними разные кренделя с регистрацией, и легко убивать, не затрагивая контейнер папу.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:27 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
вы как будто намеряно игнорируете UOW. не сложилось чтоле? об этом элегантном паттерне только ленивый не написал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:29 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Где-то в степичего стоит опасаться: 1 если объект захвачен контейнером, при повторном вызове уже освобожденного объекта - можно нарваться на инвалида. 2 если вы запустите объект куда нибудь за облака а потом его отдеспоузите через контейнер - то за облаками будет null. не стоит этого опасаться, если все классы будут делать только свою работу, и не лезть вперёд батьки, делая чужую работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:31 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Где-то в степихочу ( и призываю вас подвести резюме) по поводу освобождения ресурсов через di. резюме очень простое. определись. либо ты поручаешь DI полностью управлять выданными ресурсами (их созданием и уничтожением), либо делаешь это сам (сам дёргаешь из контейнера сервисы, и сам их уничтожаешь). не надо вот это вот. об этом сервисе DI пусть позаботиться, а вот этот я сам убью. хреновая практика это. остальное by design. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:38 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVostt, что значит поручить di? как была работа с уничтожением по надобности так и будет, не зависимо откуда объект. я ведь у ди могу и не поставить using или Dispose, и никакого освобождение ( декларированого) не произойдет, только коллектором через финализатор в будущем,.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:46 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVostt, как ты не понимаешь, оберни ты в единицу работы объекты либо работай непосредственно с объектом, это освобождение уже не контейнером. Те же самые яйца, только через дополнительную абстракцию. Ты точно так же контролируешь жизнь объекта руками через using. А мне не нужны в данном случае дополнительные абстракции в виде единицы работы, у меня и так в руках абстракция сервиса и я знаю, что именно сейчас нужно его шлепнуть. Зачем мне "шлепнуть" дополнительно паковать в UoW? Это называется бездумное программирование ради программирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:52 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Где-то в степиhVostt, что значит поручить di? как была работа с уничтожением по надобности так и будет, не зависимо откуда объект. я ведь у ди могу и не поставить using или Dispose, и никакого освобождение ( декларированого) не произойдет, только коллектором через финализатор в будущем,.... т.е. считаешь, если у зависимости имеется IDisposable, значит потребитель во что бы то ни стало должен сделать Dispose? (как минимум в конце своей жизни) ну тогда DI должен всегда создавать новый экземпляр каждой зависимости. никакого времени жизни у компонентов больше нет. или по обстоятельствам? предлагаешь компонентам вот такие коменты писать: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:54 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVostt, по обстоятельствам, я уже ранее высказал свою точку зрение на эти сервисы времени жизни, - фуфло.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 23:59 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
МСУhVostt, как ты не понимаешь, оберни ты в единицу работы объекты либо работай непосредственно с объектом, это освобождение уже не контейнером. Те же самые яйца, только через дополнительную абстракцию. Ты точно так же контролируешь жизнь объекта руками через using. А мне не нужны в данном случае дополнительные абстракции в виде единицы работы, у меня и так в руках абстракция сервиса и я знаю, что именно сейчас нужно его шлепнуть. Зачем мне "шлепнуть" дополнительно паковать в UoW? Это называется бездумное программирование ради программирования. это ты не понимаешь в чем смысл наличия Dispose у единицы работы. для удобства. UOW может быть и таким: Код: c# 1. 2. 3. 4. что поменялось? просто стало менее удобно им пользоваться. не получится RAII. МСУи я знаю, что именно сейчас нужно его шлепнуть ну тогда тебе точно DI ни в одно место не впился. ты всё итак знаешь. так можно и компилятор подвинуть. суть в том, чтобы не знать. а ты норовишь у контекста вызвать диспоуз, аж кипятком писаешь. причин не объсняешь, надеюсь это не какая-то травма в детстве? МСУЗачем мне "шлепнуть" дополнительно паковать в UoW? я попытаюсь тебе объяснить. потому что может быть ему ещё рано умирать. может конечно и сразу сдохнуть, а может еще пожить и послужить. не тебе решать. а контейнеру DI. представь твоим компонентом IDataContext пользуется другой программист. и ты ему забыл объяснить, что его надо сразу, сабаку такую, убивать на месте. без суда и следствия. и без вопросов!... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:00 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Где-то в степипо обстоятельствам ну ок. твоё право. тогда мне добавить больше нечего, я тоже высказал свою точку зрения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:01 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVosttГде-то в степи ну тогда DI должен всегда создавать новый экземпляр каждой зависимости. никакого времени жизни у компонентов больше нет. Создавать всегда новый экземпляр - не вопрос, вопрос в том, как и где нужно шлепнуть этот экземпляр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:01 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
МСУСоздавать всегда новый экземпляр - не вопрос, вопрос в том, как и где нужно шлепнуть этот экземпляр. лишь бы без фанатизма ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:04 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVostt, Код: c# 1. это обыкновенная защита от дурака, которую Вы идеализируете, Dispose в финализаторе - то же защита от дурака, но право никто же ее не идеализирует.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:05 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVosttэто ты не понимаешь в чем смысл наличия Dispose у единицы работы. для удобства. Я понимаю смысл UoW, в данном случае он вообще не в кассу. Вот для таких задач он в кассу. У абстракции сервиса есть Dispose, я его и вызываю по месту. hVosttну тогда тебе точно DI ни в одно место не впился. ты всё итак знаешь. так можно и компилятор подвинуть. суть в том, чтобы не знать. а ты норовишь у контекста вызвать диспоуз, аж кипятком писаешь. причин не объсняешь, надеюсь это не какая-то травма в детстве? Я не понимаю, смысл DI только в управлении жизнью через UoW? То есть если мне не нужен в данной задаче UoW, значит мне не нужен DI? Бред. Я уже писал, нынешние DI контейнеры могут много чего, но если я чем-то не пользуюсь, это не значит, что мне не нужен функционал DI. Тем более когда идет речь о диспоузинге по месту. hVosttМСУЗачем мне "шлепнуть" дополнительно паковать в UoW? я попытаюсь тебе объяснить. потому что может быть ему ещё рано умирать. может конечно и сразу сдохнуть, а может еще пожить и послужить. не тебе решать. а контейнеру DI. Не рано - это 100%. Я дергаю веб сервис, получаю данные и мне сразу же нужно закрыть сокет, чтобы не держать дорогостоящее соединение. Никаких пожить сервису! hVosttпредставь твоим компонентом IDataContext пользуется другой программист. и ты ему забыл объяснить, что его надо сразу, сабаку такую, убивать на месте. без суда и следствия. и без вопросов!... Ради бога. У моего IDataContext есть IDisposable, если у программиста есть голова на плечах, он должен будет высвобождать объект при ненадобности. Классика вроде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:07 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
Где-то в степиэто обыкновенная защита от дурака, которую Вы идеализируете, Dispose в финализаторе - то же защита от дурака, но право никто же ее не идеализирует.. ну хз. не вижу причин обсирать малину. есть хороший приём, существуют богатые на возможности инструменты. нахрена городить какую-то хрень, если сразу можно обеспечить соблюдение принципов SOLID и да. защита от дурака это очень важно. ибо мы люди, а не роботы, и не можем помнить досканально каждую строчку кода проекта, и как с чем надо себя вести. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:08 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
МСУРади бога. У моего IDataContext есть IDisposable, если у программиста есть голова на плечах, он должен будет высвобождать объект при ненадобности. Классика вроде. классика, если ты самолично его получил. через new или Container.GiveMeThisItem(). А если тебе его сунули через инъекцию зависимости, такого права уже у тебя нет. есть только допущение, о том, что ты можешь так сделать и тебе ничего за это не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:10 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVosttМСУСоздавать всегда новый экземпляр - не вопрос, вопрос в том, как и где нужно шлепнуть этот экземпляр. лишь бы без фанатизма Я с тобой согласен, есть куча задач с life time, когда с уничтожением по дефолту справляется контейнер. Особенно если идет речь о веб приложениях, так вообще всё просто - жизнь на реквест и море по колено. Но в долгоиграющих песочницах такие шутки уже не прокатят, нужен целенаправленный продуманный ход: попользовался дорогостоящим - освободи, иначе он будет сидеть долго и упорно в "вечном контексте". Вот что я хотел до тебя довести. И только. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:10 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
МСУНикаких пожить сервису! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:11 |
|
||
|
комисарское тело di
|
|||
|---|---|---|---|
|
#18+
hVosttМСУРади бога. У моего IDataContext есть IDisposable, если у программиста есть голова на плечах, он должен будет высвобождать объект при ненадобности. Классика вроде. классика, если ты самолично его получил. через new или Container.GiveMeThisItem(). А если тебе его сунули через инъекцию зависимости, такого права уже у тебя нет. есть только допущение, о том, что ты можешь так сделать и тебе ничего за это не будет. А не вызывает подозрение, что тебе инжектировали диспосабельный экземпляр? Уже повод задуматься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2013, 00:12 |
|
||
|
|

start [/forum/topic.php?fid=18&msg=38477411&tid=1357911]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 223ms |
| total: | 354ms |

| 0 / 0 |
