Изменить реализацию зависимости от объекта после одноэлементной реализации

Question

Итак, у меня есть класс viewmodel в проекте xamarin, в который я вставляю некоторые зависимости через привязку ninject при запуске приложения. Одним из них является IDialogService.

Когда моя MainPage в моем приложении изменяется, он вызывает событие измененного свойства, и я перепривязываю реализацию службы диалога, так как она связана с MainPage.

Если моя view-модель уже была создана с помощью, скажем, DialogServiceA, а затем, когда MainPage изменится, мы снова свяжемся с DialogServiceB, будет ли моя view-модель использовать службу A или B? Я думаю, что он использует A и, следовательно, не отображается в пользовательском интерфейсе, потому что он связан с MainPage, который больше не существует.

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

Кроме того, если этот подход совершенно неверен, поправьте меня.

Answer 1

Ты прав. Переконфигурация контейнера не влияет на уже созданные объекты.

Если вы хотите изменить зависимости без повторного создания экземпляра зависимого (родительский ViewModel), у вас есть несколько возможностей:

• использовать фабрику для создания экземпляра сервиса каждый раз. Реализуйте абстрактную фабрику (сайт от Mark Seeman) или используйте для этого Ninject.Extensions.Factory.
• вместо непосредственного внедрения службы добавьте адаптер. Затем адаптер перенаправляет запрос в соответствующий в данный момент сервис. Для этого либо вся услуга может быть введена в адаптер, либо вы можете использовать фабрику, как описано выше.
• вместо непосредственного внедрения службы введите прокси. Прокси-сервер очень похож на адаптер, но вместо того, чтобы кодировать каждое перенаправление метода / свойства, вы кодируете общий редирект с помощью перехватчика. Вот учебник по замку динамического прокси

В конце концов, однако, я считаю, что вам также понадобится способ определить, когда следует сменить услугу / какой она должна быть. Вероятно, существует альтернатива дизайна, которая не основана на обмене объектами таким образом... что сделает его более простым (и, следовательно, лучше?).

Изменить: я только что увидел, что вы также пометили вопрос как xamarin-формы. В этом случае, скорее всего, не будет возможности использовать ни динамический прокси, ни ninject.extensions.factory (он также полагается на динамические прокси). Зачем? Динамическое излучение через прокси / IL поддерживается не на всех платформах, AFAIR, в частности, на устройствах Apple, этого сделать нельзя.