Дочерние контейнеры в MvvmCross IoC

У меня есть приложение WPF MVVM, которое я хотел бы реорганизовать, чтобы использовать MvvmCross для поддержки реализаций WPF и Mono для Android.

В настоящее время мы используем Unity 3.0 для внедрения зависимостей и полагаемся на его поддержку иерархий контейнеров (один основной контейнер с основным представлением, моделью представления и службами; и для каждого сеанса с сервером дочерний контейнер с представлениями, моделями представлений и службами, которые имеют ограниченный срок службы). Может ли IoC в MvvmCross поддерживать дочерние контейнеры? Если нет, то как бы вы порекомендовали реализовать внешний IoC, совместимый с MvvmCross?

Обновление: нам не нужно поддерживать несколько дочерних контейнеров — в каждый момент времени активен только один дочерний контейнер.

Спасибо!


mvvm mvvmcross inversion-of-control ioc-container
person HolySamosa    schedule 13.05.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Фреймворк MvvmCross в его нынешнем виде в основном ориентирован на разработку «мобильных» и «планшетных» приложений. В этой области до сих пор я встречал не так много ситуаций, когда вам нужно несколько контейнеров, поэтому фреймворк принял простой подход с одним контейнером.

Если вам нужно несколько контейнеров, то MvvmCross разработан таким образом, что все можно переопределить, если вы этого захотите. Поэтому, если вы хотите переопределить используемую библиотеку IoC, вы должны иметь возможность использовать любой контейнер PCL IoC (или вводить другие собственные). Для каждого из них вам потребуется предоставить адаптер для нашего интерфейса IoC — см. IMvxIoCProvider.cs

В дополнение к этому, хотя я не полностью понимаю ваши текущие потребности (я понимаю код лучше, чем текст!), другие возможности, которые могут подойти для вашей конкретной проблемной области, включают:

  • вы всегда можете оставить текущий контейнер MvvmCross на месте для объектов MvvmCross, но использовать отдельную систему IoC для своих классов. Хотя этот сообщение в блоге о создании custom Custom ViewModelLocator помог @gshackles на пути к использованию TinyIoC и внедрению конструктора — посмотрите, что он создал в https://github.com/gshackles/CrossBar

  • Контейнер MvvmCross позволяет вам заменить резолверы, если вам это нужно - т.е. если у вас зарегистрирован один тип для интерфейса IMyService, то регистрация второго типа заменит первый.

  • вы можете зарегистрировать второй IoCContainer с основным контейнером MvvmCross - сделав это, вы затем сможете предоставить свои дочерние объекты через этот второй контейнер. Это может быть не идеальное внедрение конструктора, но оно должно позволить вам точно контролировать жизненный цикл дочернего контейнера.

  • с некоторыми небольшими изменениями (наследованием) вы можете легко создать несколько копий текущий «простой» контейнер MvvmCross — единственное, что в настоящее время заставляет этот объект быть синглтоном, — это его наследование.

  • с некоторыми небольшими изменениями (добавлено virtual в методы интерфейса) вы также можете рассмотреть возможность наследования от SimpleContainer, чтобы переопределить функциональность и предоставить несколько словарей преобразователя.

В целом, я думаю, у вас должно быть много вариантов для этого... Одна вещь, на которую следует обратить внимание, это убедиться, что вы понимаете жизненный цикл ваших контейнеров на каждой платформе приложений. Жизненные циклы WPF просты: приложения запускаются, приложения закрываются, но приложения для WindowsPhone, WindowsStore и Android можно запускать по-разному (с помощью ярлыков, захоронения, поиска и т. д.).

person Stuart    schedule 14.05.2013
comment
Спасибо, Стюарт. Для нашего сценария я думаю, что мне может сойти с рук удаление дочернего контейнера и выполнение вызовов RegisterSingleton() для замены моих синглетонов сервисных объектов по мере необходимости. Это может позволить мне работать со встроенным IoC MvvmCross. - person HolySamosa; 15.05.2013