MVVM ViewModelLocator с Ninject

Question

У меня есть много кода, который использует ViewModelLocator для установки datacontext в представлениях.

В настоящее время я использую простой сервисный локатор (Simple Injector/CuttingEdge.ServiceLocation), так что ViewModelLocator с конструктором без параметров может быть создан из XAML в Window или UserControl.Resources, а затем используется для установки DataContext.

Я в процессе перехода к использованию Ninject и думал, что смогу продолжать использовать ViewModelLocator таким же образом. Однако теперь я обнаружил, что Ninject не поддерживает прямую поддержку местоположения службы (and it appears that service location is a concept that has fallen out of favor).

Я хотел бы продолжить определение вида viewmodel из XAML (используя производный класс ViewModelLocator), но я не могу найти аккуратное выполнение этого с помощью Ninject.

Я не могу найти способ сделать это. Как другие разработчики делают это без контейнера IoC, который поддерживает IServiceLocator (или аналогичный)?

Примечания:

• только MVVM библиотека Я использую MvvmFoundation.Wpf Джоша Смита.
• Я видел сообщение в блоге Use Ninject to decouple discovery of your viewmodel's in mvvmlight's viewmodellocator, но этот метод кажется неправильным.

Answer 1

Действительно сервисный локатор, как концепция, выпадает из милости. Но иногда, как описано в вашем случае, когда вы используете подход ViewFirst, вам нужно создать экземпляр ViewModel в разметке XAML. Я настоятельно рекомендую не делать этого и вернуться к подходу ViewModelFirst, но я понимаю, что вы не можете изменить весь мир за раз. В исходной структуре caliburn были расширения разметки, которые позволяли разрешать экземпляры кода XAML. У Caliburn была какая-то абстракция контейнера, доступная из статического класса IoC. Вы можете найти код разметки здесь:

http://caliburn.codeplex.com/SourceControl/latest#src/Caliburn.PresentationFramework/ResolveExtension.wpf.cs

совет

я, что вы не используете службы локатора абстракций как в Microsoft Common Service Locator, но непосредственно обращаться в ваш статическом глобальный IResolutionRoot и устраняющий оттуда с обычаем реализованной разметки расширения , Это не должно быть слишком сложно реализовать. Как только у вас будет это, я начну переработку вашего решения в подходе VMFirst, чтобы вы могли устранить необходимость в разрешении зависимостей с помощью Locator и опереться на более обратный подход к управлению.