|
1. Modules. Composite application allows you to build clients composed of independent
modules. These modules make application composite.
|
CAB supports modules derived from ModuleInit class and IModule interface. IModule
interface declares AddServices() and Load() methods.
|
N/a
|
Modules are IModule interface implementing classes. IModule declares Initialize()
method.
|
Modules in Silverlight are assemblies packed into the Xap file or retrieved from
the server by demand.
|
|
|
1.1. Configuration
|
CAB supports modules configuration in XML file in the form:
<Modules>
<ModuleInfo AssemblyFile="BankTellerModule.dll" />
<ModuleInfo AssemblyFile="CustomerMapExtensionModule.dll"
/> </Modules>
|
N/a
|
There is no configuration file for modules. Bootstrapper class is responsible for
modules initialization. Modules initialization is hardcoded in Bootstrapper Initialize()
method.
|
Xaml supports assembly definition in xmlns sections.
|
Modules can be configured in Application.Resources property.
|
|
1.2. Initialization
|
CAB calls AddServices() and Load() methods for each module while application initializing.
|
N/a
|
Bootstrapper calls Initialize() for each module. Each module registers
views, presenters, services calling IUnityContainer RegisterInstance or RegisterType
methods.
|
Any object can be declared in Application.Resources. Initialization can be made
in constructor or in Application.Startup event handler declared in object. No convention
is required about class type. The order in Xaml specifies the order of initialization.
Xaml supports parameters for modules. App.xaml can be retrieved from application
assembly to Xap and configured on the fly by server.
|
Silverlight supports native mechanisms without extra coding.
|
|
|
|
2. Central Storage. Central storage supports independent module interaction sharing
common services, presenters and viewers. Modules add their own resources here identifying
them by string names.
|
CAB supports Items, Services, SmartParts, Workspaces collections to support common
object sharing. It’s difficult to understand what is the difference between Services,
SmartParts and Items :).
|
AcropolisApplication contains ChildParts, Services, ContractTypes collections.
|
Prism supports IUnityContainer RegisterInstance, RegisterType and Resolve methods.
It uses string name and Type to identify object.
|
Any object declared in Application.Resources can be accessible by its x:Key. Any
module can add its own global objects using App.Current.Resources.Add("x:Key",
SomeService). Objects can be accessible either from Xaml ({StaticResource}
construction) or from code (App.Current.Resources["x:Key"]).
|
Silverlight supports native mechanisms without extra coding.
|
|
|
|
3. Application state. Composite application simplifies application state saving
and loading.
|
CAB manages state declaring WorkItem.State property. You can load and save your
parameters in/from State["Key"].
|
N/a
|
N/a
|
Silverlight declares IsolatedStorageSettings.ApplicationSettings. It supports methods
for adding, retrieving, changing and removing values.
|
Silverlight supports native mechanisms without extra coding.
|
|
|
|
4. Business logic. Business logic is represented by invisible classes serving user
interface modules
|
|
|
|
|
|
|
4.1. Services/Web-services. Services are reusable components that do not require
a user interface. For example authentication, logging services.
|
CAB services are classes marked as ServiceAttribute. Cab declares the following
common services: Event Broker Service, Module Loader Service, Authentication Service,
State Persistence Service.
|
ServiceBase derived classes. ServiceProduction attribute can be set with service
type (interface).
|
Services are represented in Prism as interfaces and its implementations. There is
no base class for them. Services can be without interface definitions. Services
are global shared objects and are accessible through Central Storage (see item 2).
|
Silverlight supports web services. No special base classes for simple services available.
|
The best approach is to use objects without common base classes with or without
interface definition. The best place to access them is Application.Resources.
|
|
4.2. Presenters. Presenters (or Controllers in MVC) are the layer between viewers
and services or models.
|
Presenters are CompositeUI.Controller derived classes. They can store information
in WorkItem.State collection.
|
Part derived classes with XAML configuration.
|
There is no base class for presenters in Prism. Presenters declared as some interface
implementations. No Xaml file is associated with it.
|
According to Silverlight nature Presenters can be any classes implementing INotifyPropertyChanged
which objects are declared in control DataContext property.
|
Silverlight provides all the functionality to work with properties. No extra coding
is needed.
|
|
|
|
5. User Interface
|
|
|
|
|
|
|
5.1. Shell. Application main form
|
CAB declares Shell in FormShellApplication typed class.
|
N/a
|
Shell is created in Bootstrapper.InitializeShell() method in code.
|
Silverlight application initializes Shell (RootVisual) in Application Startup event
handler.
|
ScabApplication<TShell> derived applications are not supported in Silverlight
2 beta 2. Some workarounds are accessible and they broke normal Visual Studio Tools
work. Native Silverlight approach is enough to implement operations with shell.
|
|
5.2. Views
|
CAB view is UserControl derived class with SmartPart attribute. CAB is responsible
for adding presenters to views properties marked by CreateNew attributes.
|
PartView derived classes
|
There is no base class for views in Prism. Views declared like some interface implementations.
View has Xaml file with UserControl root element.
|
All Silverlight controls support DataContext property and can be a View.
|
Every control (UserControl) can play a view role. Developers can use the following
Xaml for example and declare View and Presenter:
<UserControl DataContext="{StaticResource PartGlobalResource}">
<TextBox Text="{Binding Zoom, Mode=TwoWay}" ></TextBox>
</UserControl>
Where PartGlobalResource is INotifyPropertyChanged Presenter
|
|
5.3. Panes/Workspaces. Workspaces/Panes are components that encapsulate a particular
visual way of displaying UI controls
|
CAB Workspaces are IWorkspace implementing classes. They use native WinForms Control
objects and SmartPartInfo to specify additional information like tab titles.
|
|
|
|
|
|
5.3.1. Layout panes enables you to show and hide several views
|
Represented by WindowWorkspace, MdiWorkspace, TabWorkspace, DeckWorkspace, ZoneWorkspace.
|
Represented by TabLayoutPane, SplitLayoutPane
|
N/a
|
Silverlight provides StackPanel (=ZoneWorkspace), TabControl (=TabWorkspace)
|
StackPanel and TabControl can be used without changes and inheritance. DeckWorkspace,
MdiWorkspace and WindowWorkspace can be implemented in additional assembly.
|
|
5.3.2. View place holder. Enables you show one view.
|
Represented by Workspace
|
Represented by PartPane
|
N/a
|
Provides ContentControl component
|
ContentControl can be used
|
|
|
|
6. Others (For example commands routing or event brokers)
|
Other features are not used often and can be implemented like services by demand.
|