Is there a way to create a product (Software) divided in modules?
What I mean is for example create an application using WPF that is divided in 3 modules (in the future they may be more) Main Module, Module 1, Module 2
Each module could be a standalone solution. Each of them with presentation, Business and Data access layers.
From the Main Module when a button is clicked, it will call any other module for example module 1 but the UI of the module should be seen like if it were from the main Module.
I have manage to use MEF to separate project building but I don now how to use MEF with WPF
Any Starting point or suggestion?
Putting your business and data access layers in a MEF module is fairly straightforward and accomplished as you would for any other project, the trick with WPF is adding the view resources. That can be done by putting them in a ResourceDictionary decorated with the Export attribute and merged into the global dictionary, as shown in the answer to "How to provide XAML resources from MEF components".
Related
I have a WPF application that uses a layered architecture with three conventional layers: User Interface, Business Logic, and Data Layer. Now I have a requirement to split the application into vertical slices by functional areas (e.g. Customer, Product, Order). Meanwhile I would like to keep the horizontal layer separation within each vertical slice.
I am considering to use the PRISM modularity framework to accomplish this. So each functional area (vertical slice) will be represented as a PRISM module. But since my modules have a layered architecture, each module may consist of multiple assemblies.
Based on the PRISM documentation the ModuleCatalog assumes that each module is in one assembly. I am not sure how I can group multiple assemblies as one module. Any ideas if this can be done?
Edit -- I missed to mention that I want to de-couple the layers by not directly referencing the implementing assemblies for the layers. Instead I define the interfaces in an interface project for the respective layer such that only the interface project is referenced by the layer using it. Given this I still need a way to tell a module about the implementing assemblies for its layers.
You're over thinking it. Your other assemblies will just be references in your Module project. You will only add the module to the ModuleCatalog, and as long as you have your referenced assemblies in place it will work as expected.
Have build composite WPF App with Unity Ioc (without Prism).
All my resources (Styles, Templates, Pics) stored in one module (Infrastructure) and merged in Shell-module's App.xaml.
In other modules I use it as StaticResource. Everything works fine when I start the project, but in VisualStudio Designer I can't see my Styles: 'the resource xyz could not be resolved'.
How should I configure VS to see all resources also in designtime?
Possible Solutions:
I could merge everything in each module, but then each resource would be loaded multiple. I could also write my own ResourceDictionary implementation (like: here), but I used to merge resources anyway everywhere - I would avoid this.
I have found a Prism reference solution for a composite application. I don't know how, but there it works without custom ResourceDictionary and without merging it in each module. VS Designer shows everything, although XAML Editor still says "the resource xyz could not be resolved"
Question: is it a feature of Prism? Or there is some configuration hidden?
Solution is simple (has nothing with Prism to do).
All resources should be defined in Shell module (not in Infrastructure module).
Then all modules should be referenced in Shell module project.
No need to merge resources in each module.
Each module knows only high level modules, and only shell knows everyone.
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'm new to Prism and have a conceptual question.
What I want to build is a Silverlight app that can load its layout (and the modules that are used) from a config file. Imagine I have a number of modules (e.g. a Chart, a Treeview and a Newsticker) and I want to use my config file to determine which of those are visible in my app and also where they are located on screen.
So if I want to have an app with just a Graph and a Treeview but not a Newsticker, would it be enough to just create an XAML file that contains views to those two modules? Would this XAML file be the shell?
Could I then have different XAML files/shells/config files to "generate" different looking applications at startup?
I don't need to switch layouts at runtime, I just want to be able to easily configure my application to use a different set of modules. I would appreciate pointers in the right direction.
Here are some approaches that I found:
http://blog.roundthecampfire.net/2011/10/creating-composable-ui-with-f-and-prism.html
http://www.dotnetpatterns.net/content/147-Lesson-2-Prism-creating-a-dynamic-region-layout-with-templates
I am developing a WPF application using the CAG from Prism. What I want to achieve is create new instances of a module (ModuleA) and load them in a TabControl.
I am able to instantiate the modules using the moduleInfo object and loading them through the Assembly and calling the CreateModule(type) method.
I can actually see the different modules in the UI, but the problem is when I start interacting with the different modules (for e.g. loading or unloading views in scoped regions) all the activity seems to happen only on the last loaded modules.
So for e.g. I have 2 'instances' of ModuleA as 2 TabItems and they both have command buttons to Load() new views. When I select the first Module (by selecting the first TabItem) and click the button to laod the view, the view gets loaded in the second module.
Anyone know how to sort this problem? Makes me believe, even if I 'see' two seperate modules on the UI, there is actually only one instance or the CreateModule creates clones ?
Anyone ? all help appreciated !
As Erik explained, loading Modules and Views are very different concepts in Prism.
The following threads are useful when understanding this and deal with a scenario similar to the one from the question:
http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=59827
http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=59040
I hope this is useful.
Thanks,
Damian