I have developed a Microsoft Prism 4.0 application and I am struggling to understand how to make the user application setting functionality available to modules.
e.g. a Properties.Settings.Default.MyProperty.
I can define a simple class that gets populated via the bootloader (which does have a handle to the properties) and inject that into the modules but If I want to save a change of property, I need believe I need a handle to the Properties.Settings context which is not available to my modules (which are simple class libraries).
Your scenario sounds like the perfect reason to use a "Service" class. Create an interface and class called IUserSettingsService and UserSettingsService that has the information (or can load and save it from where it is stored).
Read Chapter 3 of the Prism 4.0 help file, Managing Dependencies Between Components, Registering Types with (either Unity or MEF, depending on what you are using as your DI Container).
Then, in your ViewModel that needs the user settings, locate and use your service. In MEF, it is as simple as adding a property of type IUserSettingsService with an [Import] attribute, or using [ImportingConstructor] and having a parameter of type IUserSettingsService. With Unity, you access the service through the container. See Chapter 10 of the Prism help file - Advanced MVVM Scenarios.
Added after comment discussion:
Because you need your service to be in the context of your main application, you can implement your service class there. Create the interface for your service in a shared library that can be used by both the main project and your modules. Finally, load the service in the bootloader class instead of in a module.
Related
Can we have Unity configuration in file other than app.config file of the application? If yes, how to do it?
Can we combine unity configuration spread across multiple files?
How to define Unity configuration in the XAML file? (PRISM modules can be configured in XAML.)
Is it possible to have custom implementation of the Microsoft.Practices.Unity.Configuration.UnityConfigurationSection configuration reader class?
We are developing a WPF application which should allow other developers (working on various ares of the enterprise app) to register their XAML views (user controls) with our application. And depending on the functionality being used, our product will navigate user to the appropriate form/view. E.g. On click of the "Home" button, user would be navigated to the "Dashboard". But Dashboard may or may not be developed by the core product.
I am using Prism 4.1.
I believe that pretty much everything you need is explained in the following section of Unity's documentation:
Using Design-Time Configuration
It describes how to load one or several "configurations" into a Unity container from the default configuration file or from several other independent files.
Based on this, I believe you should be able to have a configuration file in each of your modules and load them manually in the Initialize method (or the module classes' constructors). If not, you can always register the corresponding type mappings programatically in the modules too.
We have a product which acts as a base framework for other applications/teams.
I am declaring type mappings through unity configuration. On the other hand, every configured module has its IModule implementation in which we map a view with predefined region.
However, to achieve this, every other 'module' project team has to write its IModule implementation and do 'region mapping/registration' themselves in the code.
Is it somehow possible for every module to tell my base product that it wants to register X, Y, Z types/instances through unity "configuration"? My base framework will resolve types/instances and do appropriate mappings. It will allow module teams to focus just on their WPF business views instead of implementing IModule etc.
At present, type mapping is possible in unity but I cannot associate registration with the Prism module. Further, it's not possible to map a resolved type with the predefined region.
E.g. In our application Shell we have a region named 'BusinessRegion'. We have an interface called IBusinessView. Every module will have several business views. Depending on module & its workflow, we have to navigate from one business view to another. However, at present I cannot know which business view belongs to which module.
The same question is already answered in the following CodePlex forum site:
Can we do WPF view-region mapping & interface-type mappings in the configuration?
As commented at CodePlex's, there wouldn't be possible to know which View belongs to each Module after they are initialized. Views and components get registered in the Container and Regions, loosing any dependency reference with the Module.
Regards.
I have read in "Dependency Injection in .NET" by Mark Seemann that there should be a single place (per each) where Register, Resolve and Release have to be called. Now, I'm trying to set up the environment of a new WPF project. Our team has decided to use Caliburn.Micro as MVVM-framework with MEF as IoC.
So, I clearly understand where Register has to be called, but what about Resolve?
I also have read in the book, that in ASP.NET MVC app there is a place where Resolve has to be called:
override IController GetControllerInstance(RequestContext requestContext,
Type controllerType) {
return (IController)this.container.Resolve(controllerType);
}
But where should the call reside within a WPF app? Besides, can Caliburn help somehow with accomplishing this issue?
But where should the call reside within a WPF app? Besides, can Caliburn help somehow with accomplishing this issue?
Actually Caliburn.Micro handles this part for you, because when you derive your bootstrapper from the existing BootstrapperBase or Bootstrapper<TRootModel>, those bootstrappers call a method called Start() that initiaties a sequence of activities which composes the entire object graph of your application starting with TRootModel or whatever you call DisplayRootViewFor(Type viewModelType) for.
I am very new to WPF.
I am trying to figure out pros/cons of various architecture patterns in WPF, while creating an application designed to interact with a database.
The application begins with a master window, which contains various buttons which load other windows which each perform CRUD operations on different tables within that DB.
I am wondering about the merits and disadvantages of 3 possible approaches:
1) Instantiate a new entity instance within the constructor for each window
2) Each window have a have a constructor which supports dependency injection of the entity object. Every time the master window instantiates a new window object, it injects its own instance of the entity.
3) As per WPF Data Binding Walkthrough Create public ObjectResult properties on a class which inherits from application, and link to this/these properties in the
<Window.Resources><CollectionViewSource>
Tag of the various windows.
Thanks
Dependency Injection is the best option giving you most flexibility...
However, you shouldn't inject something as specific as the entity object but some service provider instead which would be a specific implementation of a service Interface and would not use the entity object directly but a Model instead which would abstract away the data access specifics giving you loose coupling benefits...
I'm using Prism to build my application and 19 of my modules need to interact with an control from another module.
Is there any way to expose a control? I really don't want to use the event system because it would too much of the responsibility on my one know to know about the data being passed to it.
If you do not wish to use the event aggregator, you could also register something (ie a service, whos interface is defined in your infrastructure dll) with dependency injection that interacts with the control directly.
You can always create a separate project that holds "Infrastructure" controls that each module references. This way they gain access to say CommonWindow etc..