Design Patterns

A design pattern is a general, reusable solution to a commonly occurring software problem. A design pattern is not a finished specification that can be transformed directly into code. Instead, it is a template for solving a particular problem. Thinking in terms of design patterns allows you to formulate a high-level solution that is independent of the implementation details. Using established design patterns leads to a solution that is easily understandable, testable, and maintainable.

For example, the Partner Portal and Training Management applications use versions of the Model-View-Presenter (MVP) pattern. Designing the applications in an MVP pattern structures the applications' layers and increases the testability of the business logic that is in the Web Form code-behind files. Code-behind files are a convenient place to locate both the event handlers and the view logic. However, the event handlers are private methods, and the forms must be rendered to test the view logic. This makes it difficult to develop automated unit tests. Another problem is that, although it performs separate functions, the business logic is intermixed with the view logic. Factoring out the business logic into a separate presenter class allows you to unit test it in isolation and separates it from the view logic.

Enterprise-scale SharePoint applications include many cooperating services and application layers. The Partner Portal application implements several patterns that group related functions into discrete layers. As a result, the application is modular and supports the principle of separation of concerns. In turn, this encapsulation improves the application's testability.

The Partner Portal application implements the following patterns:

• The Model-View-Presenter (MVP) Pattern
• The Repository Pattern
• The Service Locator Pattern
• The Trusted Façade Pattern

The following diagram illustrates the patterns that are used in the Partner Portal application and shows how they relate to the application layers.

Patterns used in the Partner Portal application

The Training Management application also shows how patterns can improve an application. The initial implementation did not use patterns. The following diagram illustrates the initial architecture of the Training Management application before it was refactored.

Unfactored Training Management application

The initial implementation had the following problems:

• Both the .aspx pages and the Web Parts had view logic intermixed with business logic. This made it difficult to unit test the business logic.
• The ASPX Pages, the Web Parts, and the workflow activities had static references to service assemblies that were part of the line-of-business (LOB) systems. Fixed dependencies on LOB systems, which are typically not available in development or test environments, make unit testing difficult.
• The .aspx Pages, the Web Parts, and the workflow activities directly accessed data from SharePoint lists. This resulted in a great deal of duplicated list access code. Some of the code did not follow best practices for performance and for secure list access.

The following diagram illustrates the architecture of the Training Management application after it was refactored and reorganized according to the MVP pattern.

Factored Training Management application

The refactored application supports unit testing. The MVP pattern separates the view logic from the business logic. The SharePoint list repositories encapsulate the list access code, and the service locator places a layer of abstraction between the application and the dependent services. The end result produces results in increased test coverage of the business logic, and a better separation of the view and business logic. The refactoring and restructuring also help to remove duplicated logic and improve the long-term maintainability of the application.

Home page on MSDN | Community site