This project has moved and is read-only. For the latest updates, please go here.


Context Manager

Prism normally by default makes users put everything in one global container.  AppCan lets you define contextdefinitions to wrap sets of functionality (like a view and it's viewmodel plus related classes) that will be instantiated into contexts.  This allows the use of standard interfaces for views (IView) and viewmodels (IViewModel) so that compositing applications can be done by modules without even needing to know the specific interfaces/types in some cases.  Prism docs suggest having a different interface for everything (that would seem to make components coupled somewhat, albeit at least to interfaces.  This stems from Prism normally using a single global container.  With AppCan that specific interface coupling can be unnecessary as the generic interfaces can be used instead since there are many containers rather than one global one.)


The context manager is created in the AppCanApp base class.  The context manager holds context definitions, which in turn context definitions can create contexts.   Context definitions are created to provide a context for standard components you use together, like a view, viewmodel and regions (plus any other classes you would like the container to be able to instantiate for you for that context.)   Contexts will get created either when you request them to be created from the contextmanager or contextdef (context definition), or when a region that is mapped to a context gets created it will automatically instantiate the context.  Prism normally by default makes you put everything in one global container.  AppCan lets you define contextdefinitions to wrap sets of functionality (like a view and it's viewmodel plus related classes) that will be instantiated into contexts.


IServiceReplicator ContextManager internally creates an ServiceReplicator (IServiceReplicator) that can be resolved from the RootContainer.  Registering types through the ServiceReplicator rather than a container directly will propogate those instances to all newly created contexts. (If you don't use the replicator the contexts probably would only contain the views/view models that you added to the manually.  Using the Service replicator it allows your objects created in that context to resolve any of the replicated services from the existing context).

Context Manager 


- The context manager is used to get/create context definitions

IContextDef contextDef=_app.ContextManager.GetNewOrExistingContextDef("HelloWorld.Shell")


- Get a new context

IContext context=_app.ContextManager.GetNewOrExistingContext("HelloWorld.Shell")

- Load context configuration



ContextDef  (Context Definitions)

Context definitons provide a way to group together logical sets of objects in the same IUnityContainer.  A definition is just the registrations of your types that will be available to be instatiated in a context.  (There is one context definition with a given name, but there can be many Contexts.)  An example of a logical set of classes to include in the same definition would be a View and a View Model.  In AppCan that would mean a type that derives from IView or (IViewContainer) and a type that derives from IViewModel. 

The reason to do this is so that objects can be resolved by generic interfaces when possible to allow for easier replacement of objects by modules that might wish to create composite interfaces.  By doing this generic objects can easily be substituted for Views or View Models.  View Models often don't have any code that references them directly and they are just bound by element name in Xaml.  If a developer wanted to replace the view model with another object, as long as the same bound names were used it would work.  You should not typically resolve objects from the context definition that you have created since they will typically get resolved in the context (there are some exceptions to this guideline.)


Example of registering a view and a view model to a ContextDef:

_app.ContextManager.GetNewOrExistingContextDef(ContextNames.HelloWorldShell).Container.RegisterType<IViewModel, ShellViewModel>(new ContainerControlledLifetimeManager());

_app.ContextManager.GetNewOrExistingContextDef(ContextNames.HelloWorldShell).Container.RegisterType<IViewContainer, Shell>(new ContainerControlledLifetimeManager());


IContextRegionManager is available in a ContextDef for wpf applications

Context region managers are used to register mapping of types to regions.  When Context's get created from the ContextDef the regions are added into the local region manager that is available in a Context.  This allows for mapping to local regions in a particular view, that allows re-use of the same region names in views.  In fact we highly recommend when possible using standard region names so that it would be easy to know for someone adding new functionality the right region of a window to add to.  For example MenuRegion, ToolbarRegion,MainRegion, StatusbarRegion  might be a standard layout you may wish to use.

Example of Xaml in a window or user control using a local region manager:

<ItemsControl Name="MainRegion" cal:RegionManager.RegionManager="{Binding Path=LocalRegionManager}" cal:RegionManager.RegionName="{x:Static local:RegionNames.MainRegion}" />

The above Xaml relies on using the AppCan IViewModel that defines the LocalRegionManager property.  In the View model if a IRegionManager interface is specified in the constructor it will get the local region manager for the context it was created from.


 Context's /IContext

Context's are created from context definitions.  They contain child IUnityContainers  of  ContextDef so all of your registered types are available to be Resolved there.  The contexts will have the actual instances of objects that have been instantiated when they are resolved.


Example of a context being created and used:

Context ct =_app.ContextManager.GetNewOrExistingContextDef(ContextNames.HelloWorldShell).GetNewContext(); 
_window = (Window)ct.Container.Resolve<IViewContainer>();



Last edited May 23, 2013 at 3:59 AM by davesspacebar, version 11


No comments yet.