Assume that there is WPF application which uses MVVM light toolkit.
Good example of this toolkit is Locator. It is great it contains SimpleIoC which enables us to register Services and be Interface Driven.
Sometimes Locator constructor can really grows. Unfortunatelly besides registering Interfaces it contains some logic as.:
if(SimpleIoc.Default.GetInstance<MainViewModel>().LoadProject())
{
var project = SimpleIoc.Default.GetInstance<MainViewModel>().LoadedProject
SimpleIoc.Default.Register<ConfigService>(new Service(project))
}
It was only an example - what If I need more logic during Locator Constructor. Maybe my Services Architecture is wrongly created since they they are not independent or Maybe in such cases I should resign Locator usage - but then I will lost DI.
Another things is that in few ViewModels there is Reference to Locator.GetInstance which I found another not a good practise since it should be injected via contructor to enable testability.
Another aspect is Using it correctly with AvalonDock.
AvalonDock is great anchorable control which enable to prepare apps which could be similar to such apps as Visual Studio with anchorable, dockable panes.
This panes are actualy another ViewModels which are bound to AvalonDock via property.
MainViewModel has property Tools = new Tools[] { ViewModel1, ViewModel2}
But each ViewModel was registered in Locator.
therefore I am using (violate DRY) them in MainViewModel as
Property getter: Locator.GetInstance()
which is in my opinion another bad example - even not safe. What if any service required by Avalon Tool ViewModel1 is not registered yet but it is invoked via getter during MainViewModel instantiation.
It started to be a mismatch. Do you have any good practise?
I found many examples such as Workspaces (MainViewModel) but nobody used at the same time Locator which I found very useful.
I would like to keep Locator because I consider it to be a good thing which enables mme to have my project testable thanks to dependency Injection and Interface Driven.
Any Ideas suggestions? I would be thankful.
I'd avoid this. As you rightly point out, there is a lot more going on here then simply registering types.
Instead, I'd pass the ConfigService instance to the Viewmodel in its constructor. As long as it is register first, you can IOC the config service and view model.
... That's all from memory so might not be accurate but does show the custom constructor idea from SimpleIOC.
In your view model constructor you can then call the service .Register method passing itself as a parameter.
That keeps the 'knowledge' in your view model and your locator stays focused on doing what it should.