The code for this lesson is attached at the bottom.
A special thanks to Telerik for making wonderful RAD controls which make our development lives a lot easier.
The Demo versions of 2010 Q1 WPF were used and can be found at the Telerik website. http://www.telerik.com/account/free-trials/single-trial.aspx?pid=601 All the assemblies used for the demo are contained in the SharedAssemblies folder in case you need to redefine any references.
A big thanks to Sacha Barber for Cinch, Josh Smith for all his work and RelayCommand and the others who have taken the time to post helpful work on the internet.
Now let's get started with Lesson 3. In the real world the only thing constant is change. The concept of modules introduced with Prism is a good idea for larger projects. However, inevitably there is going to come a time when there are views in a module that need to be used throughout the application from within other modules.
In our lessons, we are using the Northwind database. (Not needed for this lesson.)
This lesson assumes we have decided we need a module for Customers, a module for Employees and also a separate module for Orders.
The issue here is that both Customer & Employees are associated with orders. We wouldn’t want to have to duplicate the code from the orders module for both the employees & customers modules. (One option would be to create a module and that contained functionality to handle all three areas. However, for the purposes of this lesson we’re going to assume they all need to be separate.)
For this to happen, we need to come up with a way for other modules to utilize the OrderView. There are different ways to do this, but based on the info I’ve read, I chose to create the OrderController in the Order module assembly to accomplish this.
Since multiple modules will need access to the controller, the interface IOrderController was defined in the Infrastructure assembly. This interface will define the Public methods available to any assembly in the solution.
We create OrderType which consists of an OrderTypes enum that declares Employee & Customer because when we load the View, we need to know if we are loading Customer or Employee orders. We also pass in an Id of type string. CustomerId is of a type string and an OrderId is of type int. We convert the Id to the appropriate type as necessary.
Once we have the IOrderController object defined in the infrastructure assembly, we can obtain a reference to it via Dependency Injection. For our sample to work, we obtain this reference in the Customer & Order ViewModel constructors.
In the constructor, the following code from the CustomerViewModel constructor, we make a call to IOrderController.GetOrders()
Code:
_regionManager.Regions[RegionNames.CustomerOrderRegion].Add(_orderController.GetOrders(new OrderType { Type = OrderTypes.Customer, Id = string.Empty }),
Code:
RegionNames.CustomerOrderRegion);
Now when you load the Customer Template, the CustomerModule code runs which Resolves CustomerViewModel. This causes CustomerViewModel to initialize. This in turn causes the code listed above in the constructor to run, which makes a call to get the correct orders for the selected Customer or Employee. Again, this is determined by the OrderType param passed to GetOrders.
Please note that this lesson’s purpose is only to show how to load the OrderView in the CustomerTemplate and the EmployeeTemplate.
Attached is the source code. The next lessons will get into creating data models and services to interface with the Northwind database.
Below are some screen shots of the Customer & Employee modules being loaded.
CustomerTemplate
EmployeeTemplate







Section Widget
Categories Widget (top-down)


Rate this article