|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
Такой вот вопрос. Допустим, я для своих целей использую Ninject, конструкторы/свойства/методы максимально отвязаны от конкретных реализаций, и оперируют интерфейсами. Соответственно, для обращения к ним нужно отрезолвить нужные зависимости, и передать нужным образом. Для резолвинга нужен экземпляр IoC-контейнера. Лучшие собаководы вроде как рекомендуют инжектить зависимости в нужном наборе фабрик в нужных местах (а не в точке входа в приложение всем скопом), далее использовать фабрики. Тут начинаются вопросы: 1) мы начнем обращаться к конкретным реализациям фабрик? Но получается же, что DI, таким образом, нарушается - в точке вызова мы оперируем с конкретной реализацией? 2) допустим, мы заинжектили и фабрики. Но тогда в точках обращения к фабрикам нам опять нужна ссылка на контейнер. И где этот контейнер хранить? Сделать его синглтоном и чем-то типа ServiceLocator? Опять получаем зависимость от конкретной реализации, причем сквозную по всему проекту. Наконец, причем здесь MVVM. Если речь идет о невизуальных классах с узкой спецификой, то мы можем их инжектить максимально близко к точке использования. А вот если, например, нам надо заинжектить что-то типа IMessageBoxService, используемый во всех моделях приложения? Инжектить его в конструкторе каждой модели - не видно особого смысла, т.к. у сервиса нет состояния, и он один абсолютно одинаковый для всех. А если не инжектить в каждой модели - то надо инжектить один раз на всё приложение. Опять упираемся во что-то типа сервис-локатора-синглтона. И что тут делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 08:19 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC LacksА вот если, например, нам надо заинжектить что-то типа IMessageBoxService, используемый во всех моделях приложения? Инжектить его в конструкторе каждой модели - не видно особого смысла, т.к. у сервиса нет состояния, и он один абсолютно одинаковый для всех.Сегодня нет состояния, завтра может появиться. Сегодня он синглетон, завтра он ThreadStatic-синглетон, послезавтра ещё что... Но это маразм конечно, основанный на неуверенности в завтрашнем дне. зы: У нас MessageBoxService всегда был обычным статическим классом, дискомфорта никакого... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 08:57 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC LacksИнжектить его в конструкторе каждой модели - не видно особого смысла, т.к. у сервиса нет состояния, и он один абсолютно одинаковый для всех. А если не инжектить в каждой модели - то надо инжектить один раз на всё приложение.Инжектить можно через публичные свойства, вынесенные в базовый для всех вьюмоделей класс. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 08:59 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
Алексей Кзы: У нас MessageBoxService всегда был обычным статическим классом, дискомфорта никакого... +100 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 09:41 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
Алексей КУ нас MessageBoxService всегда был обычным статическим классом, дискомфорта никакого... У вас никогда не было автоматизированного тестирования. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 10:34 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
SolYUtorАлексей КУ нас MessageBoxService всегда был обычным статическим классом, дискомфорта никакого... У вас никогда не было автоматизированного тестирования. :) Тестировать мессадж бокс? Не смеши :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 10:37 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC Lacks, Вы не понимаете принцип Dependency Inversion, и соответсвенно технику применения Dependecy Injection контейнеров. Всё о чём вы пишите - сплошной анти-паттерн ServiceLocator . Какую зависимость какой компонент получит - надо решать на уровне конфигурации контейнера, а не в классах приложения. Абстрактные фабрики при наличии контейнера - ненужная вещь. Контейнер и так классная фабрика, сделает что надо, сколько надо, и когда надо. Для вашего IMessageBoxService можно использовать то, что Seamann назыает Ambient Contex (хотя я бы всё равно инжектил). Только не забудьте его инициализировать его при старте приложения, и предусмотреть возможность замены. Чтобы привести мысли в правильное русло раздобудьте себе Dependency Injection in .NET . Там кратко и по делу. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 10:44 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
SolYUtorМСУЧего вы там во вьюмоделе/контроллере/презентере тестировать собрались? Тестировать модель надо, а она далека от MessageBoxService. Не надо мешать логику с UI, тогда костыли не понадобятся. Тестировщики-любители блин... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 11:12 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
Так я же и пишу, что стараюсь уйти от вариантов с ServiceLocator'ом. Основной вопрос сводился к следующему: допустим, мы определили зависимости для компонентов в конфигурации контейнера. Теперь в нужном месте нам по зависимости нужен экземпляр компонента. У кого его получить? у контейнера? А откуда получить контейнер? Каждый раз его инстанциировать заново? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 11:31 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC LacksТак я же и пишу, что стараюсь уйти от вариантов с ServiceLocator'ом. Основной вопрос сводился к следующему: допустим, мы определили зависимости для компонентов в конфигурации контейнера. Теперь в нужном месте нам по зависимости нужен экземпляр компонента. У кого его получить? у контейнера? А откуда получить контейнер? Каждый раз его инстанциировать заново? Ну, видимо, контейнер создаётся при старте приложения. "Корневой" сервис создаётся через явное обращение к этому контейнеру. А дальше всё через иньекции. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 11:36 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC LacksА откуда получить контейнер? Каждый раз его инстанциировать заново? Это же статика, экземпляр контейнера один. Код: c# 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 11:44 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
Алексей Ке надо мешать логику с UI, тогда костыли не понадобятся. Тестировщики-любители блин... А логику представления тестировать не надо например? Скажем есть у нас кнопка "DeleteFoo" у которой свойство Enabled прибиндено к свойству модели MVVM DeleteEnabled. Свойство должно быть true, только если юзер выбрал объект, и этот объект не удалён. При вызове delete спросить уверен ли юзер в своём желании удалять. Если не уверен - не удалять. Это всё логика, которой не место в бизнес слое. Ее можно и полезно тестировать. Тестировщик-профессионал, блин. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 12:06 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
SolYUtorА логику представления тестировать не надо например? Скажем есть у нас кнопка "DeleteFoo" у которой свойство Enabled прибиндено к свойству модели MVVM DeleteEnabled. Свойство должно быть true, только если юзер выбрал объект, и этот объект не удалён. При вызове delete спросить уверен ли юзер в своём желании удалять. Если не уверен - не удалять. Это всё логика, которой не место в бизнес слое. Ее можно и полезно тестировать.Тестировать "это" - маразм. SolYUtorТестировщик-профессионал, блин. :)Да. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 12:16 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
МСУЭто же статика, экземпляр контейнера один. Код: c# 1.
В случае с упомянутым Ninject пример использования выглядит примерно как Код: c# 1. 2. 3. 4.
В случае, например, с Castle Windsor, код немногим отличается: Код: c# 1. 2. 3. 4.
- контейнер инстанциируется явным образом. Т.е. для того, чтобы им воспользоваться, мы должны либо поместить его внутрь синглтона/статического класса - получаем ServiceLocator, либо хранить где-то в корне приложения ссылку, и постоянно передавать её по цепочке в конструкторы. Ни то, ни другое у меня как-то не вызывают оптимизма. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 12:18 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC LacksТ.е. для того, чтобы им воспользоваться, мы должны либо поместить его внутрь синглтона/статического класса - получаем ServiceLocator, либо хранить где-то в корне приложения ссылку, и постоянно передавать её по цепочке в конструкторы. Ни то, ни другое у меня как-то не вызывают оптимизма.Есть смысл ещё раз прочитать мои ответы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 12:21 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
Алексей КНу, видимо, контейнер создаётся при старте приложения. "Корневой" сервис создаётся через явное обращение к этому контейнеру. А дальше всё через иньекции. Алексей КЕсть смысл ещё раз прочитать мои ответы. Редкий случай, когда я согласен с Алексеем. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 12:42 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC Lacksконтейнер инстанциируется явным образом И в чем проблема? IoC LacksТ.е. для того, чтобы им воспользоваться, мы должны либо поместить его внутрь синглтона/статического класса - получаем ServiceLocator Глупости. 1. Синглтон не обязан быть сервис локатором. 2. Причем тут синглтон? Он не панацея. 3. Причем тут статический класс? Класс не обязан быть статическим, речь о статическом методе и только. 4. Достаточно иметь статический метод, который будет отдавать отрезолвленный интерфейс. IoC LacksНи то, ни другое у меня как-то не вызывают оптимизма. У тебя каша в голове. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 12:45 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
МСУУ тебя каша в голове. Касательно обсуждаемой темы - не спорю. Иначе зачем мне было бы эту тему заводить? Я и рассчитываю с помощью этой темы несколько разобраться в обсуждаемом. Итак, насколько я понял, мне намекают на что-то типа Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
и далее в коде Код: c# 1.
так? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 13:03 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC Lacksи далее в коде при старте приложения Код: c# 1.
Добавил. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 13:20 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC Lacksтак? Типа того. Вот код штатного DI для ASP.NET MVC Код: c# 1. 2. 3. 4. 5. 6.
Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
DependencyResolver Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 13:33 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
IoC LacksМСУУ тебя каша в голове. Касательно обсуждаемой темы - не спорю. Иначе зачем мне было бы эту тему заводить? Я и рассчитываю с помощью этой темы несколько разобраться в обсуждаемом. Итак, насколько я понял, мне намекают на что-то типа Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
и далее в коде Код: c# 1.
так? Эта унылая шняго из ASP.net mvc создана только для таких как MCУ, который в глаза не видел нормальные контейнеры. Их применение должно быть изначально заложено в архитектуру, почитай доки по prism. В них достаточно внятно объяснено для чего они нужны и что для этого должно быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 13:44 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
SeVaЭта унылая шняго из ASP.net mvc создана только для таких как MCУ, который в глаза не видел нормальные контейнеры. Это замечательный возможность использовать штатный mvc-шный резолвер. А те, вроде тебя, у кого не хватает мозгов это понять, могут вещать дальше о правильный контейнерах и убитой кастрированной поделке prism. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 14:04 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
МСУ, IDependencyResolver в MVC - это ошибка. Правильный путь - реализовывать IControllerFactory. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 14:49 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
SolYUtorМСУ, IDependencyResolver в MVC - это ошибка. С чего это? SolYUtorПравильный путь - реализовывать IControllerFactory. Путь тоже хороший, не спорю. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 14:55 |
|
IoC-контейнер для использования с MVVM: где хранить?
|
|||
---|---|---|---|
#18+
МСУ, контейнеры склонны контролировать жизненный цикл созданных ими объектов. Во многих случаях требуется явно указать контейнеру, когда объект можно уничтожать. Register-Resolve-Release цикл. Так вот, DependencyResolver не предоставляет способа "отпускать" объекты. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2013, 15:07 |
|
|
start [/forum/topic.php?fid=21&msg=38311044&tid=1441308]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
others: | 294ms |
total: | 432ms |
0 / 0 |