So I have two separate views in a WPF Prism app. How can I inject the same instance of a ViewModel into both the views via Dependency Injection?
(I assume you are using Unity as you mentioned DI directly and are not saying "Import" or similar)
Hi,
You will have to register the ViewModel as a singleton (using a ContainerControlledLifetimeManager) in the container and have it injected as usual. This ensures that you will get the same instance whenever you request for it.
A valid approach in this scenario might be to use a named registration in case you want to get the same VM injected elsewhere, but you don't need the same instance.
This article explains how to do this.
Related
I'm trying to make a module in a prism project. The module doesn't have UI(View, ViewModel). I want the module has working EventAggregator event handlers.
Is there any way?
I wonder it is possible to make service module without view, viewmodels?
Of course, it is. A module is just a late-bound, post-deployment-exchangeable collection of code. It can contain anything, be it views, view models, services, dtos...
I want the module has working EventAggregator event handlers.
... most of those can have dependencies injected because they're resolved from the container. I.e. they can use the event aggregator.
If you have services that are "on their own" (i.e. like a windows service, but in-process) or that need to be initialized early, you can resolve the service in OnInitialized and start it/initialize it.
I've created a class named JsData and instantiated it in App.xaml.cs so that I can access it from multiple viewmodels. The JsData has several ObservableCollections, some properties for configuration and some methods which manipulate the process of automatically pulling data from remote server.
Now comes the question. Is it convenient for me to bind the global data to my views with minimum coding? Besides, I'm using Caliburn.Micro. Is it doable and appropriate to notify PropertyChanged events to viewmodels using messaging?
I think the best way to do this is to create a service that your view models can implement. That way on,y the view models that need the data can implement the service, and the service is more flexible because it can be injected in the view model construction. This keep your view models more decoupled and honors the mvvm pattern.
I would not use messaging to not notify changes, that would create unnecessary overhead. You just need to have your view model implement inotifypropertychanged and then get the service in your constructor And then pass the service values to properties in your view model that raise the property changed event.
If your need help defining a service just let me know and I will post a sample
I need to display views in a Module.The Module Registers it's view using in Initialize method.
User will select module name from drop down list. First time it works using IModuleManager.LoadModule(string ModuleName). If I want to re-display the same module again(in the same region after clearing the previously displayed module) IModuleManager.LoadModule is not going to work. I dont know the views and regions contained in that Module. I know just ModuleName and I need to display it's view.
How can I do that?
Your questions is very confusing. Can you provide more information? The IRegionManager is the component to register Views to your predefined Regions. The ModuleManager is only responsible to load an assembly if I got that right.
I don't think you can Load a Module multiple times, because the second time it is loaded already. The logic for displaying views should be regulated via Services within your Modul so inside your Module should be a Method that uses the IRegionManager to register a specific View to a Region.
I don't know whether you use Unity or MEF ( or another IOC ) but you can obtain the IRegionManager within your Module via the Container.
Maybe you should watch this Tutorial series Prism Tutorial Series. It seems to me you are missing some basic principles
I have a WPF application in PRISM architecture.
From what I read on the net, I saw that it is best if the View-Models call WCF service operation i n an ASYNC manner, and also - it is best to create a new connection for each operation. (I was told it is not good to keep connections alive for too long).
My question is - how should I inject the WCF clients to my View-Model ?
If I simply create an interface for the 'auto-generated' client - and inject the interface - this will simply create an instance for the client in my View-Model constructor, but that will not help me if I want to create a new client for each operation I perform in the window.
For that - I need something like a 'client factory' to be injected.
Can anyone offer his opinion on this ?
First off, IMVHO the WCF call is best to go in the Model, not the ViewModel.
You can create a factory helper class, you pass it an interface and it passes back a concrete instance that implements that interface. The factory helper can still use PRISM to resolve the interface to a concrete type, the types will resolve whatever you have registered them to, and you will get a new instance each time provided you haven't registered them with a lifetime manager.
Using PRISM inside the factory helper helps keep the whole thing highly unit testable - you can mock out the WCF related proxy classes at test time, and the target Model will never know the difference. If you really want to follow the dependency injection pattern then you could inject the factory helper on the constructor.
I am used to using Windsor Castle IoC with MVC web applications so I'm a little familiar with registering components and bootstrapping the application.
I am now trying to create my first WPF application and I'm a little lost....
In a typical MVC project I would register all my components in Application_Start in the Global.asax file.
Also, in the Global.asax I would do something like this :
_container = new WindsorContainer();
var myControllerFactory = new MyControllerFactory(_container.Kernel);
ControllerBuilder.Current.SetControllerFactory(myControllerFactory);
In MyControllerFactory which inherits from DefaultControllerFactory I would resolve the Controller given to me, thus all the controllers being used would have their dependencies resolved automatically.
How could I do this in a WPF application ?
I created a class called ContainerBootstrapper that registers my components, and now I'm wondering how I use this in my MainWindow so every time I call a component, it's dependencies are resolved automatically...
Unlike MVC, WPF does not provide framework for decoupled UI development out of the box. There are several out there (such as Caliburn.Micro which implements the MVVM pattern) that sit on top of WPF and provide integration for a variety of IoC containers as well as other features you may find useful in WPF development.
Alternatively, you will need to manage the container directly. i.e. instantiate and initialise the container in App.xaml.cs or MainWindow.xaml.cs and ensure that new object construction via your container's Resolve() function. If it is a non-trivial app, you will probably want to integrate this into your app's navigation routines.