PRISM : Explained

Using Prism you can create a WPF application , the client-side of a silverlight application and a Windows Phone applications.

The client side application of PRISM generally has a Shell, a few modules and the infrastructure to connect these:

• Shell
• Modules
• Infrastructure 

Namespace

Namespace used in prism are

• Microsoft.Practices.Composite.dll
• Microsoft.Practices.Composite.Presentation.dll
• Microsoft.Practices.Composite.UnityExtensions.dll
• Microsoft.Practices.Unity.dll
• Microsoft.Practices.ServiceLocation.dll

Shell

The foundation of the application is “The Shell”.  The Shell is the top-level window of an application based on the Prism Composite Application Library. This window is a place to host different user interface (UI) components that exposes a way for itself to be dynamically populated by others, and it may also contain common UI elements, such as menus and toolbars. The Shell window sets the overall appearance of the application.

The shell that is responsible to load the Modules.

Module 

A module represents a set of related concerns. It can include components such as views, business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion.

Infrastructure 

The Infrastructure Assembly is a shared library referenced by both the shell project and the module projects, and holds shared types such as constants, event types, entity definitions and interfaces.

Looking inside Shell

Shell contains BootStrapper.cs

The Bootstrapper component is used by the application to initialize the various Prism components and services. It is used to initialize the dependency injection container to register any application-level components and services with it. It is also used to configure and initialize the module catalog and the shell's view and view model or presenter.

The Bootstrapper inherits from 

• Microsoft.Practices.Composite.UnityExtensions.UnityBootstrapper 

To be able to run the bootstrapper at least one module should be registered in our application. 


Shell contains Shell.xaml on to which modules are loaded.

Modules can be loaded in the regions defined in Shell.xaml.

Regions

Regions are the placeholders for the controls defined in Modules.  Modules can be added into the shell one by one , generally we add one module at begining and then continue adding more and more.
Modules can be added to regions in shell.xaml and can be added/removed at runtime.Because our application is build with modularity in mind it’s the Module and not the Shell that should define which views need to be added to the regions.

Region Manager Service

Views are created inside modules.To add views to our regions we use the prism region manager service. The region manager service is responsible for maintaining a collection of regions and creating new regions for controls.  Typically, we interact directly with region manager service to locate regions in a decoupled way through their name and add views to those regions. By default, the UnityBootstrapper base class registers an instance of this service in the application container. This means that we can obtain a reference to the region manager service in our application by using dependency injection.

So, this is how my Shell and Module talk to each other.

and following shows the basic terms in PRISM

Bootstrapper – let’s get this party started!

• Kicks off the application
• Starts the main UI container (the Shell)
• Registers Modules and loads, if needed
• Registers any global singletons (optional)

Shell – the main view (might be a master page)

• The main UI container
• Houses all of the Views that will be loaded
• Can be split into Regions
• Knows nothing of what will be loaded into it

Regions – content areas

• Area(s) in the Shell where Views can be placed
• Are given a name
• Can contain context, if needed
• RegionManager exists to help maintain Regions

Modularity – self contained modules

• To the user this is seamless
• Can be developed separately
• Does not reference other modules
• Solution is split into Modules
• Modules share infrastructure and Models

Inversion of Control (IoC)

• Unity or other Dependency Injection (DI) Tools 
• Helps for test ability and mocking
• Abstraction
• Container object allows classes to be registered against their interfaces
• When an interface is requested, the container creates the class registered with the interface
• Supports singletons

Infrastructure – common tools

• A Silverlight class library project
• Contains shareable items for the modules
• Classes
• Assets
• Resources
• Makes no references
• A pure library

Commanding – Action & Reactions

• Allows events between a View and a ViewModel through Data Binding
• ViewModel declares the Command receiver
• Command is declarative in XAML
• Button – Click,ListBox (Selector) – Selected
• Command is data bound to the ViewModel’s command receiver
• Can be disabled/enabled based on rules

Event Aggregation: Publish – Subscribe pattern

• Allows events of any kind to be published and subscribed to
• Can be cross module
• Can be filtered by subscribers
• For example:
• Click on a menu item in the Shell
• Event is invoked by the publisher
• Event is received by the subscriber
• The subscriber then loads a View in a Region in the Shell

Conclusion

Thinking of a Prism as a set of options is probably the best way.One pick only the features one really needs, and simply skip the rest. Architecture of Prism provides flexibility, and that is the first advantage of adapting it to project.

You can also read this article at dotnetspider.