Ok, I’ve been using CAB, the SCSF, in “pseudo kinda sort of” Model View Presenter Pattern usage. The application that is being developed definitely uses the core of the mentioned products. Recently as I read some techno babble by Glenn Block who works directly on the factories and tools themselves I came to a scary conclusion. Several of the prospective issues of our CAB/MVP implementation and to help further a solution for others out there using the CAB/MVP Patterns I figured I’d relate some non-business specific solutions. The bullet list below is from Glenn’s blog entry.
- Ability to support multiple teams developing different parts (modules) in isolation.
- Ability to extend existing and add new modules to the application without recompilation.
- Loosely coupled components that can share data and interact with one another as well as the UI (i.e. populate menus, toolbars, and status bars)
- Standardized and extensible layouts.
- Pluggable UI components.
- Pluggable application services that can be globally accessible such as Authorization and Authentication.
- Separation of UI, Business and Infrastructure concerns.
- UI Testability.
- Reduction of repetitive coding tasks.
- Simplified deployment.
My fears, the short list, is appended to the respective bullet point listed below.
- Ability to support multiple teams developing different parts (modules) in isolation.
[Problem][Developers, management, and other powers often push for vertical development either purposefully or accidentally.]
[Solution][When developing against CAB/MVC foundations and patterns the various layers should always be broken out to the specific teams that can best handle and develop against the specific layers.]
- Loosely coupled components that can share data and interact with one another as well as the UI (i.e. populate menus, toolbars, and status bars)
[Problem][Often groups tend to accidentally tightly couple things when development is hurried. When this occurs a major benefit becomes moot.]
[Solution][A person or persons should be delegated to refactor the code regularly to insure that the pattern stays loosely coupled. This can also be done during code reviews and turned into a great session of to-do and not to-do items. The key of staying loosely coupled is code reviews and refactoring the code on a very regular basis (weekly) to stay on top of what is going on.]
- Pluggable application services that can be globally accessible such as Authorization and Authentication.
[Problem][If the CAB/MVC is used with an architecture that does not directly allow clear modularized usage of authorization and authentication the CAB/MVC also becomes unwieldy and difficult to manage.]
[Solution][Integrate and create an LDAP based (AD if need be) security integration that can be globally accessible via the plug-able application services. Either way this scenario is always specific to the particular architecture and pattern implementation of the particular business. It is very difficult to clearly use modularized authorization and authentication when the application is many layered and complex. However, when an application is many layered and complex it is even more important that the authorization and authentication ARE modularized.]
Each of these prospective problems is easily overcome with a little development effort and acuity to code reviews and refactoring, but as always should be brought to focus right away to alleviate any magnifying schedule time and costs to a project.
