Using a Portable Area
This is the third part in a series about using a Portable Area (PA) using MvcContrib. This sample walks through the Host Application side of consuming the Login Portable area. This example demonstrates how a portable area such as a login can send messages and recieve responses from the host application. This allows the host application to control the core of the application and lets the Portable Area solve the User Interface portion of the Login. While this is a pretty simple example it is important to look at the concept of what a Portable Area could solve. A portable Area could just handling wiring up multiple user interface screens and deal with simple form validation while leaving a lot of from for the host application to control the parts that are important to the application. Or a Portable Area could provide an entire self contained piece of functionality like a Blog engine, or mulit-instance forum. There is a large spectrum for how much the Portable Area could provide. This example focuses on an example where the Portable Area provides the UI and lets the host application own the domain logic.
In order to use a Portable Area (PA), the following references need to be added to your MVC project: MvcContrib & the assembly of the Portable Area.
Wiring up the Portable Area to the application is done at startup. Portable Areas use the message bus as a way to communicate between the PA and the application. The main method for integrating with a portable area is to register a Message Handler. The sample below demonstrates wiring up a LogAllMessagesObserver, LoginHandler, and a ForgotPassword Handler for the Login Portable Area.
The call to the InputBuilder.Bootstrap() is required to initialize the Embedded Resource view engine used by this Portable Area infrastructure.
Here is an example of an Observer message handler. This handler simply logs the message to the debugger. This could be used to collect metrics about the system, or log messages to a loggin framework. The idea of an observer is that it is looking at the base message and not modifying the state of the message.
The Login Message Handler receives the login request and than sets the result object which is part of the contract that is specified by the LoginPortableArea from Part 2.
In this example the main logic for login is still in a authentication service. The handler is just used to wire up the message and response of the portable area to the host applications domain services.
Whats Next?
The constructor of the LoginHandler takes an IAuthenticationService as a dependency and my next post will walk through how an Inversion of Control container can be connected to the Bus to allow the framework of your choice to put your pieces together.
Posted
Nov 03 2009, 12:00 PM
by
erichexter