Using the instructions from http://www.milosev.com/98-c/wpf/373-autofac-and-prism-together#dependencyInjection I tried to setup my module's dependencies (eg. ViewModel requires some IServices to be constructed). The only thing I haven't used is that MEF thing but as far as I understood it is something alternative to Unity or Autofac.
I couldn't find any proper place to put the registration of types that are specific to my Module. Temporarily I use static method from my module class that is called from Bootstrapper's ConfigureContainerBuilder()
protected override void ConfigureContainerBuilder(ContainerBuilder containerBuilder)
{
base.ConfigureContainerBuilder(containerBuilder);
RoomSimulatorModule.InitializeDependencies(containerBuilder);
}
But it is called before my Module is initialised. Is there any way to add those types during module registration? Or due to the way Autofac constructs the container I can't register new types?
Related
I want to create two modules that describes toolbar and menu feature, but I don't want to define them in two different assemblies, and I tried to do it in that way,It works fine,but I'm afraid that would it takes twice as much as memory like just define them in one module? Follow is my demo code, they're written in one project.
public class MainMenuModule : IModule {
public void Initialize() {
RegionHelper.RegisterViewWithRegion(Shell.RegionNames.Menu, typeof(Views.Menu));
}
}
public class ToolBarModule : IModule {
public void Initialize() {
RegionHelper.RegisterViewWithRegion(Shell.RegionNames.ToolBarRegion, typeof(Views.ToolBar));
}
}
Note that RegionHelper is a wrapper prism region API.
That's fine. Although I don't really see a use case for two modules in one assembly...
And btw, the module definition classes are ready for collection once their Initialization methods return.
Is it OK to put two Prism modules in a single assembly? Well, yes. It will work and there is nothing stopping you from really. You can put as many module classes in a single assembly as you want to.
Keep in mind that a module is supposed to be a set of loosely coupled functional units though. If you put two modules in a single assembly, you can no longer load the first one without also loading the second one and vice versa. This may be a problem or it may not depending on how the modules are used by your application.
The possible down-sides of using too many assemblies are discussed here: Specific down-sides to many-'small'-assemblies?
This is generally not an issue.
hi we have a PRISM WPF MVP application, we would like to have a state to share data between the views in the same module. Since PRISM by default doesnt have a state, was wondering if there is any way i could implement this. Presently i have injected a State with Dictionary as back-store, but the problem is its Global i.e available across the modules. i would really like to scope this injection being module specific.
I believe unity allows registering different classes to the same interface based on name, not sure if the only choice i have is to leverage that for my scenario.
Any help would be great! Thanks!
-ioWint
I would agree, scoping Unity's type registration with the ModuleName would be a place to start.
Inject a local(module level) state object into all the views that want to have share state. If the interface that defines the state object is local to your module then other modules won't be able to reference the state object because they can't reference the interface.
So: If Module A has 3 views that take an object implementing IStatefulContainer (also declared in Module A) and IStatefulContainer is registered with Unity using RegisterInstance rather than just RegisterType you'll have a singleton that is scoped to the module.
My preference would be to have a "State" service that managed state. This could allow you to add more functionality here if you needed it and is a more "Prismy" approach.
EDIT
If you're using this state object across modules then you can do the following:
1)Put the interface in an assembly that will be referenced by any module that wants to use it.
Assembly A
public interface IBlah
{
string Add(string stateKey, string stateValue);
}
Assembly B (referencing Assembly A)
public class Module:IModule
{
private IUnityContainer _container;
public Module(IUnityContainer container)
{
_container=container;
}
public void Initialize()
{
IBlah blah1=new BlahContainer();
IBlah blah2=new BlahContainer();
_container.RegisterInstance<IBlah>(blah1,"BlahContainer1");
_container.RegisterInstance<IBlah>(blah2,"BlahContainer2");
}
}
Module C(references assembly A)
_container.Resolve<IBlah>("BlahContainer1");
_container.Resolve<IBlah>("BlahContainer2");
Basically, we define the interface in an assembly we're happy to share between modules. Some projects have "Infrastructure" or Common assemblies that contain service interfaces that are used by other modules - this would fit well here.
We then have our module reference the assembly with the contract in it.
At the moment I'm relying on "magic strings" here but there are lots of ways around this.
Hope this is a little more clear.
thanks for your updated solution. I was trying to avoid a name based Unity registration, which would force my Presenter in knowing the Modules State registration Key.
I was reading stackoverflow posts on Unity and found the discussion over here Is it possible to override parameter values when using Method Injection with Unity? .
After couple of hours of trial and errors, i ended up achieving the desired functionality.
What i have done:
I have a BaseClass for my Modules -> BaseModule:IModule i have a State Property in it which conforms to my IStateService defined in the Infrastructure.Interface. I Instantiate this State property in the BaseModule() constructor.
Note: to go with this approach i have to make my Presenter's have a public IStateService State; property..
At the time of registering the Presenter in the module, i am specifying
<UnityContainer>.RegisterType<MyPresenter, new InjectionProperty("State", State).
Am overriding a public property in Presenter which has name "State" with the State instance value defined in the Module.
this way i am able to get the Modules State as the State for each of the View's presenter.
Thanks guys for directing me towards a solution.
-ioWint
Is it possible to register a region adapter within a module?
I have a ContentControl in my Shell.xaml set to region "MainRegion" that currently gets populated with a module containing the AvalonDock control. I currently have the AvalonDock region adapter in my Shell app but would like to place it in the module and register itself. I want to keep this program flexible so that if we decide to use something other than AvalonDock, I can easily use another module without having to modify my Shell assembly (removing the avalondock region adapter).
I imagine something like this is possible. Has anyone done this before?
In bootstrapper right now is:
protected override RegionAdapterMappings ConfigureRegionAdapterMappings()
{
RegionAdapterMappings mappings = base.ConfigureRegionAdapterMappings();
var regionBehaviorFactory = Container.GetExportedValue<IRegionBehaviorFactory>();
var regionManager = Container.GetExportedValue<IRegionManager>();
mappings.RegisterMapping(typeof(Pane), new AvalonRegionAdapter(regionBehaviorFactory, regionManager));
return mappings;
}
This is what I would like to perform in the Module instead of the Shell bootstrapper.
Answer is here from codeplex http://compositewpf.codeplex.com/discussions/250892
The scenario you're describing is
possible. Although custom region
adapters are intended to be registered
in the RegionAdapterMappings in the
Bootstrapper's
ConfigureRegionAdapterMappings method,
it is possible to register a custom
region adapter from within a module.
You could, for example, obtain a
reference to the RegionAdapterMappings
in your Module class by using
constructor injection, and call the
RegisterMapping method there. This is
possible since there is a class named
MefRegionAdapterMappings, which
exports the RegionAdapterMappings as a
shared export. Note that you should be
aware of the timing issues that may
arise due to this. You should be
careful to register the custom mapping
before attempting to create a region
which uses that adapter.
I want to have create a WPF or Silverlight module which cannot only be utilised by Shell's bootstrapper, but also can be embedded in non-PRISM applications.
In short is there a way PRISM module can be intialised from module itself rather than initialsing from Shell?
Ulimate goal is to have WPF/Silverlight PRISM module, which can be initialsed by non-PRISM applications.
There is no barrier to this.
The IModule interface has a single, parameterless void method: Initialize().
A non-prism application can initialize the module by calling that method. That's it.
If the other application has a different plugin system, with a different interface, your module can implement that interface as well, and the body of whatever initialization method that interface uses can simply call Initialize(), or vice versa.
For example:
public interface IMyPluginModule
{
void StartModule();
}
public class MyModule : IModule, IMyPluginModule
{
public void Initialize()
{
// actual initialization code here
}
public void StartModule()
{
Initialize();
}
}
It's a little more complicated than it appears at first glance, but it is doable. I don't know if you are using Prism 4 yet, but if so, Microsoft actually provides guidance for this scenario:
http://msdn.microsoft.com/en-us/library/ff921109(v=PandP.40).aspx
There is a bit of project manipulation you need to do to get two projects running side-by-side. There is a sample included with Prism v4 called "MultiTargeting" if you need to see a working sample.
Your question regarding to allowing a module to be initialized by itself, rather than having the orchestrating Shell / Bootstrapper is the wrong approach, however. Essentially what you would have would be two shells... one WPF and one Silverlight. Take a look at the samples and see what you think.
Hope this helps.
In this stackoverflow question I learned that Prism/Unity is not as decoupled as I thought, e.g. if I have this class which gets menuManager injected into its constructor, then I have to make sure that this class actually exists somewhere (I thought that you could just pull the .dll that contains the class and the container would deal with it, e.g. injecting a null in its place):
public class EmployeesPresenter
{
public EmployeesPresenter(IMenuManager menuManager)
{
}
}
But I can deal with that: the application cannot run without a MenuModule (or else as was suggested I could have a NullMenuModule which does nothing but keeps the application from breaking).
However, the application I am building will have a MenuManager class in the MenuModule and every module will have to register everything it wants to have in the menu with the MenuManager. However, I want to be able to swap out MenuModules e.g. have a InfragisticsMenuModule and have a TelerikMenuModule, etc.
However, when I am in e.g. the CustomersModule, in order to use TelerikMenuModule, I need to reference it. And when I want to use InfragisticsMenuModule, I need to reference that.
So how will I be able to "hot swap" TelerikMenuModule with InfragisticsMenuModule without recompiling all my modules with new references, e.g. I want to replace this:
Application.exe
Customers.dll
TelerikMenuModule.dll
with this:
Application.exe
Customers.dll
InfragisticsMenuModule.dll
and simply be able to restart the application and it runs with the new InfragisticsMenuModule.dll and does not complain that TelerikMenuModule.dll no longer exists.
This is where interfaces come in. You need something like:
public interface IMenuSystem
{
// whatever operations need to be offered by a menu system
}
Application.exe and Customers.dll may only refer to that interface. They aren't allow to know about a specific implementation.
Then you would use configuration steps (calling Register... methods or using a config file) to specify which type will provide the implementation of MenuSystem.
For obvious reason MEF comes to mind here and is designed for stuffs like this. I haven't had a chance to use Unity, so I'm not sure if it has something built in like this (i.e. scanning a directory for an IMenuModule implementation), but MEF can do this.
Suggestion also is to put this IMenuModule in a common assembly (separate from your other assembly). I usually called this thing Something.Core.dll.
So you might have: Application.exe, Customer.dll, Application.Core.dll, and your specific MenuModule implementation.
Your specific MenuModule implementation will reference the Application.Core assembly to gain access to its IMenuModule interface and implement it there.