Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
что бы не говнокодить, надо писать сложные вещи, тогда найдешь собственные решения проблем а так, да, надо изучить чужой опыт и применить по делу (если надо че то прибить гвоздем,то надо прибивать, а можно шурупы использовать если не дорого, иликакую нить съемную челюсть щоб легче было почистить в ванночке - ну разные у людей задачи) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:18 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
ViPRosчто бы не говнокодить, надо писать сложные вещи, тогда найдешь собственные решения проблем а так, да, надо изучить чужой опыт и применить по делу (если надо че то прибить гвоздем,то надо прибивать, а можно шурупы использовать если не дорого, иликакую нить съемную челюсть щоб легче было почистить в ванночке - ну разные у людей задачи) опыт — это мудрость глупцов :) можно набить свои индивидуальные шишки, а можно обойтись без этого, воспользовавшись чужим опытом. второе типа практичней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:21 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
ViPRosну разные у людей задачи) ну и контейнеры бывают разные Концепцию DI можно и без контейнера реализовать - главное обязанности разделить и лишними знаниями классы не обременять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:24 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttничего не надо тащить в класс кроме самой зависимости. всё по-фенщую. класс объявляет через конструктор и/или через открытые свойства о своих зависимостях. DI-контейнер эти зависимости разрешает. класс ничего не знает о каких-то там областей жизни в этом и соль. это понятие DI-контейнера. при чем это может и называть-ся совершенно иначе, и реализовано может быть по-другому. Пример в студию. Мне нужно в конструкторе класса обратиться к сервису и прибить. После этого я могу в окне показать данные. Ждёмся. hVosttбанальный пример ASP.NET MVC. стандартная жизненная область -- это время жизни HttpContext. мои сервисы совершенно без понятия, что они живут в этих временных рамках. однако отдельные сервисы зарегистрированы в контейнере таким образом, что они живут ровно столько, сколько живут их прямые потребители, т.ё. каждому классу выдаётся совершенно новый экземпляр. и ему не нужно заботиться об уничтожении. когда он умрёт, его зависимости умрут. с этим прекрасно српавляется контейнер. Пример веб реквеста очень прост, тут вопросов нем. Вопросы появляются, когда в конкретном месте мне нужен диспоуз. hVosttно! как только мы начинаем в этой схеме использовать SL, то уже всё внешнее управление временем жизни летит к чертям. оно уже не нужно. получил инстанс через DependencyResolver, уже буть добр уничтож его сам. вот такая вафля. разница величиной в пропасть, не смотря на кажущееся родство обоих паттернов. Если в DependencyResolver нет управления жизнью, это еще не значит, что это локатор. Во-вторых, для веба его хватает за глаза. Для десктопа нужен контейнер посильнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:25 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
МСУЯ же тебе давал ссылки. Практикуются, ибо это удобно. Во-вторых, не все DI контейнеры имеют именованные области жизни. В-третьих, намного проще освободить, чем делегировать освобождение. И самое главное - нету серебряной пули. Вот что я хочу, чтобы ты понял. так чем ж проще самому диспозить? то ли это будет делать контейнер, то ли это будешь делать ты. мало того, что изменится ситуация, придётся перелопатить кучу классов, или вместо этого достаточно в одном месте регистрации изменить порядок освобожнения зависимости. серебрянной пули нет. но мы же не об этом. я не ратую за то, что DI лучше или хуже чем что-либо другое. и что одно его применение сразу решит все проблемы. просто мне непонятна смесь DI + SL, как ты используешь. может это конечно и удобно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:27 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttIMyAggregateService Ну композитный класс это, конечно, выход. Но вглядит всё-равно стрёмно. Опять же, так и не увидел реальных причин, по которым "запрещено" протаскивать контейнер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:27 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
ИзопропилКонцепцию DI можно и без контейнера реализовать - главное обязанности разделить и лишними знаниями классы не обременять Золотые слова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:28 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttможно набить свои индивидуальные шишки, а можно обойтись без этого, воспользовавшись чужим опытом. второе типа практичней. не всегда это так вот ты я смотрю ты уже полгода с этим ДИ, СЛ трахаешься, и сам признал что все еще не до конца почувствовал оргазм а если б жисть заставила изучать не ДИ СЛ а просто испытаь нормальный оргазм, ты б быстро нашел как это делается а так все эти паттерны ведут к одной скрытой цели - ты пишеь предложение на каком нить чукчинсом языке и - начинается парсеры, онтологии, тезаурусы, грамматики... и вот сгенерирован внутренний запрос и отправлен в сеть для поиска соответствия, разрешения, генерации ответа ... если цель ясна, то дорога видна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:29 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
МСУПример в студию. Мне нужно в конструкторе класса обратиться к сервису и прибить. После этого я могу в окне показать данные. Ждёмся. МСУВопросы появляются, когда в конкретном месте мне нужен диспоуз. блин кому нужно? классу или сервису? вот это убъёт зависимость сразу же, как убъёт класс: builder.RegisterType<X>().InstancePerDependency(); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:31 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
МСУОпять же, так и не увидел реальных причин, по которым "запрещено" протаскивать контейнер. жесткая зависимость от контейнера. мало? потеря контроля за выдачей экземпляров. вместо автоматического разрешения зависимостей, мануальная терапия. есть ли в этом такая необходимость? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:32 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttМСУЯ же тебе давал ссылки. Практикуются, ибо это удобно. Во-вторых, не все DI контейнеры имеют именованные области жизни. В-третьих, намного проще освободить, чем делегировать освобождение. И самое главное - нету серебряной пули. Вот что я хочу, чтобы ты понял. так чем ж проще самому диспозить? то ли это будет делать контейнер, то ли это будешь делать ты. мало того, что изменится ситуация, придётся перелопатить кучу классов, или вместо этого достаточно в одном месте регистрации изменить порядок освобожнения зависимости. серебрянной пули нет. но мы же не об этом. я не ратую за то, что DI лучше или хуже чем что-либо другое. и что одно его применение сразу решит все проблемы. просто мне непонятна смесь DI + SL, как ты используешь. может это конечно и удобно... Давай еще раз. Вот мой класс - вью модель в WPF, в которую я протаскиваю контейнер и радуюсь жизни: [ Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Сделай мне тоже самое с помощью своим управлением жизни. Еще раз подчеркну: очень важно, чтобы диспоуз был сразу после вызова метода GetData(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:33 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttМСУПример в студию. Мне нужно в конструкторе класса обратиться к сервису и прибить. После этого я могу в окне показать данные. Ждёмся. МСУВопросы появляются, когда в конкретном месте мне нужен диспоуз. блин кому нужно? классу или сервису? вот это убъёт зависимость сразу же, как убъёт класс: builder.RegisterType<X>().InstancePerDependency(); Я же сказал, не катит. Класс должен жить. Выше я дал пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:34 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttМСУОпять же, так и не увидел реальных причин, по которым "запрещено" протаскивать контейнер. жесткая зависимость от контейнера. мало? потеря контроля за выдачей экземпляров. вместо автоматического разрешения зависимостей, мануальная терапия. есть ли в этом такая необходимость? Я готов зависеть от контейнера. Контроль выдачи не теряется, ты о чем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:36 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
МСУ, Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. вообще, вью-модель не должна сама получать данные из контекста. поэтому у тебя такая хрень. я бы убрал зависимость от IDataContext из вью-модели. это неправильно если ты делаешь MVC/MVP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:42 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
МСУЯ готов зависеть от контейнера. Контроль выдачи не теряется, ты о чем? ну если признать это за аксиому, мои доводы все до единого бессмысленны. я не готов зависеть от контейнера. я хочу иметь возможность малой кровью отделаться от Autofac и перейти на Unity, или на Ninject. я хочу управлять зависимостями в одном месте. исопльзовать модульную композицию. именно поэтому я никогда не использую DependencyResolver. за ненадобностью. у каждого класса своя маленькая область ответственности. он выполняет всего лишь свою задачку и никуда больше не лезет. поэтмоу в моём проекте не существует классов с десятками зависимостей. не больше 1-3 зависимостей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:45 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttМСУ, Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. вообще, вью-модель не должна сама получать данные из контекста. поэтому у тебя такая хрень. я бы убрал зависимость от IDataContext из вью-модели. это неправильно если ты делаешь MVC/MVP. 1. Мне нужен диспоуз после GetData. Где решение? 2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия. Где решение??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:50 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttМСУЯ готов зависеть от контейнера. Контроль выдачи не теряется, ты о чем? ну если признать это за аксиому, мои доводы все до единого бессмысленны. А в чем проблема зависимости от контейнера? Ну ладно, допустим я буду в ViewModel подавать сервисы, хрен с тобой. Но мне всё-равно нужно отдиспоузить сервис после GetData. Где решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:51 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
hVosttвообще, вью-модель не должна сама получать данные из контекста. А вообще сразу невооруженным глазом видно, про MVVM не слыхал :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:53 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
МСУ, авторМне нужен диспоуз после GetData. Где решение? раскомментируй /// Вообще то что ты пытаешься прикрутить диспоус к di это круто, то о чем много говорят ( о жизни объекта) как бы к самой жизни его как объекта ( в понимании расхода памяти и ресурсов ядра) не имеет вообще отношения, это банальный кеш а вот время кеша и определяем этими терминами, вообще то объект может и не иметь механизма освобождения ресурсов.. хочешь диспозить - диспозь в ручную, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2013, 23:59 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
МСУhVosttМСУ, Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. вообще, вью-модель не должна сама получать данные из контекста. поэтому у тебя такая хрень. я бы убрал зависимость от IDataContext из вью-модели. это неправильно если ты делаешь MVC/MVP. 1. Мне нужен диспоуз после GetData. Где решение? 2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия. Где решение??? Муслима, грузить данные в конструкторе - полный маразм и блокировка экрана. Решение простое - сервис навигации и асинхронная загрузка данных, те нормальный фреймворк, а не пионерский бред. Твое понимание mvvm совершенно тупое - навесить на него все и вся(навигацию, валидацию, DAL, еtc), те довести до неудобоваримого состояния. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 00:01 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
Где-то в степихочешь диспозить - диспозь в ручную, контейнеру предварительно имеет смысл сообщить, что временем жизни собирается управлять клиент - и никаких проблем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 00:07 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
Если в ГовноДатаСервисе необходим режим per-call, то он должен сам закрывать неуправляемые ресурсы (соединение с БД, wcf proxy) и ничего тогда диспозить не нужно. net прекрасно все уберет сам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 00:21 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
Изопропил, время жизни, это время жизни, а использование уже созданного объекта - тут я не знаю, подойдет ли этот термин для того о чем говорим. вот предположим, определили мы объект с параметром ContainerControlledLifetimeManager по существу синглтон для созданого контейнера, или еще как ну для контекста запроса. или для потока, дак ты его задиспоз до дыр он никуда не исчезнет пока на него ссылка будет указываться в контейнере, потом да, при определенных условиях он отдиспозится как надо, и исключение что обратились к уничтоженному объекту не сгенерится, ибо ссылка на него живее всех живых - на время кеша. ресурсы ядра - да освободятся, а коллектор его не приберет, вообще лично мне не нравится вот эта вся банальщина вот пример реализации Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 00:23 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
SeVaМСУпропущено... 1. Мне нужен диспоуз после GetData. Где решение? 2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия. Где решение??? Муслима, грузить данные в конструкторе - полный маразм и блокировка экрана. Решение простое - сервис навигации и асинхронная загрузка данных, те нормальный фреймворк, а не пионерский бред. Твое понимание mvvm совершенно тупое - навесить на него все и вся(навигацию, валидацию, DAL, еtc), те довести до неудобоваримого состояния. Дурилка, маразм у тебя в башке, а не в конструкторе. Никакой блокировки экрана не будет, будут доступны все формы, кроме той, которая тормозит. Это не сильверлайт с одним окном в браузере. Городить асинхроннын окна тут смысла не имеет. Твое понимание дотнета поверхностное и ограниченное. В конструкторе - инициализация данных. После загрузки окна возможны снова обращения к сервисам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 00:24 |
|
||
|
выбор IoC
|
|||
|---|---|---|---|
|
#18+
ИзопропилГде-то в степихочешь диспозить - диспозь в ручную, контейнеру предварительно имеет смысл сообщить, что временем жизни собирается управлять клиент - и никаких проблем В юнити даже life time режим такой есть. Это нормальная практика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2013, 00:27 |
|
||
|
|

start [/forum/topic.php?fid=18&msg=38476010&tid=1357917]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 425ms |

| 0 / 0 |
