Loading modules based on rules. This allows you to only load modules that are applicable for a specific role. An application might retrieve from a service the list of modules to load.
Loading modules from different locations. A Windows Presentation Foundation (WPF) application might retrieve modules from the Web, from the file system and/or from a database. A Silverlight application might load modules from different XAP files. However, most of the time, the modules come from one location; for example, there is a specific folder that contains the modules or they are in the same XAP file.
guidelines for developing a modular system:
- should be opaque to the rest of the system and initialized through a well known interface
- modules should not directly reference one another or the application that loaded them
- should use loosely coupled techniques such as shared services to communicate to each other or to the application that loaded them instead of communicating directly
- modules should not be responsible for managing dependencies. should be managed externally through dependency injection
- should not rely on static methods, which inhibits testability
- modules should support being added and removed from the system in a pluggable fashion
design a modular system:
- define module's responsibilities
- module to have distinct set of responsibilities
- each module consists of its own presentation layer, business layer and resource access layer
communication patterns between modules:
- loosely coupled events: publish and subscribe to events for communciation between modules. pattern works when the number of events required to fulfill a task is small. otherwise, overheads happen due to wait time for the event triggers.
- shared services: a class that can be accessed through a common interface. a shared assembly containing common functions such as authentication, logging, configuration is an example.
- shared resources: modules can communicate indirectly through a database or web service instead of communication directly
team development using modules:
- infrastructure team: cross module interfaces and functionality such as logging, authentication
- ui team: shell and visual components design
- operations team: managing deployment of modules
UI composition:
views from multiple modules have to be displayed at run time in specific locations within an application's UI
developer defines layout with named locations within which the views will be displayed at run time
layout can evolve independently wihtout affecting the modules that are adding views to the layout
shell of the application defines the layout at the highest level
the module that defines the view and the view being displayed doesn't have knowledge of how it be displayed in the named location
view discovery approach for composite ui design:
modules can register views against a particular location
when that location is displayed at run time, the registered view will be automatically created and displayed
modules register views with the registry
parent view queries the registry for views registered with a particular location
displays views in the named location control
after the application is loaded, the composite view is notified to handle the placement of views that are added to the registry
composiste application library defines a standard registry called RegionViewRegistry to register views for named locations
view injection approach to composite ui design:
views are programmatically added or removed from a named location by the modules that manage them
application contains a registry of named locations
module can lookup locations in the registry and programmatically inject views into it
the locations adhere to a common interface to inject views
composiste application libarary defines a standard registry called RegionManager and an interface called IRegion for view injection
--> when to use view discovery versus view injection, see the UI Composition technical concept.
Loading modules from different locations. A Windows Presentation Foundation (WPF) application might retrieve modules from the Web, from the file system and/or from a database. A Silverlight application might load modules from different XAP files. However, most of the time, the modules come from one location; for example, there is a specific folder that contains the modules or they are in the same XAP file.
guidelines for developing a modular system:
- should be opaque to the rest of the system and initialized through a well known interface
- modules should not directly reference one another or the application that loaded them
- should use loosely coupled techniques such as shared services to communicate to each other or to the application that loaded them instead of communicating directly
- modules should not be responsible for managing dependencies. should be managed externally through dependency injection
- should not rely on static methods, which inhibits testability
- modules should support being added and removed from the system in a pluggable fashion
design a modular system:
- define module's responsibilities
- module to have distinct set of responsibilities
- each module consists of its own presentation layer, business layer and resource access layer
communication patterns between modules:
- loosely coupled events: publish and subscribe to events for communciation between modules. pattern works when the number of events required to fulfill a task is small. otherwise, overheads happen due to wait time for the event triggers.
- shared services: a class that can be accessed through a common interface. a shared assembly containing common functions such as authentication, logging, configuration is an example.
- shared resources: modules can communicate indirectly through a database or web service instead of communication directly
team development using modules:
- infrastructure team: cross module interfaces and functionality such as logging, authentication
- ui team: shell and visual components design
- operations team: managing deployment of modules
UI composition:
views from multiple modules have to be displayed at run time in specific locations within an application's UI
developer defines layout with named locations within which the views will be displayed at run time
layout can evolve independently wihtout affecting the modules that are adding views to the layout
shell of the application defines the layout at the highest level
the module that defines the view and the view being displayed doesn't have knowledge of how it be displayed in the named location
view discovery approach for composite ui design:
modules can register views against a particular location
when that location is displayed at run time, the registered view will be automatically created and displayed
modules register views with the registry
parent view queries the registry for views registered with a particular location
displays views in the named location control
after the application is loaded, the composite view is notified to handle the placement of views that are added to the registry
composiste application library defines a standard registry called RegionViewRegistry to register views for named locations
view injection approach to composite ui design:
views are programmatically added or removed from a named location by the modules that manage them
application contains a registry of named locations
module can lookup locations in the registry and programmatically inject views into it
the locations adhere to a common interface to inject views
composiste application libarary defines a standard registry called RegionManager and an interface called IRegion for view injection
--> when to use view discovery versus view injection, see the UI Composition technical concept.
No comments:
Post a Comment