Design Patterns

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The Training Management application uses three patterns. They are:

• Model-View-Presenter (MVP)
• Service Locator
• Repository

A design pattern is a general, reusable solution to a commonly occurring problem in software. A design pattern is not a finished design that can be transformed directly into code. It is a description or 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.

For example, the Training Management application uses a simplified version of the MVP pattern to increase the testability of the business logic that is in the Web Form code-behind files. These code-behind files are a convenient place to locate 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. Another problem is that 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. To learn more about common software design patterns, see MartinFowler.com.

The MVP Pattern

The Training Management application uses a simplified version of the Model-View-Presenter (MVP) pattern. This pattern separates the application's data, data specifications, data manipulations, application coordination, user interactions, and presentation functions into specialized components. This pattern is not required for SharePoint applications. It facilitates the software development technique of unit testing with mock objects. This technique breaks the dependency on external components, such as SharePoint. The mock objects emulate SharePoint behaviors during the unit tests.

The Model-View-Presenter pattern that is used by the Training Management application contains presenter classes to encapsulate the business logic. Presenters act on the properties of views and update them. The Training Management presenters access list items through repositories instead of through SharePoint itself. Repositories are abstract layers that wrap the access logic to the training and registration SharePoint lists. Organizing the application this way allows the inputs to the layers to be simulated by the mock objects.

For more information about mock objects, see Martin Fowler's article Mocks Aren't Stubs. For more information about the Training Management unit tests, see Unit Testing. For a discussion of the MVP pattern, see Derek Greer's discussion, Interactive Application Architecture Patterns.

The Repository Pattern

Repositories act as mediators, or interface layers, between different parts of an application. The Training Management application uses repositories to manage persistence of information. The Training Management repositories are responsible for querying SharePoint and for updating SharePoint list items.

Retrieving data from SharePoint lists requires careful use of the SharePoint API, knowledge of the GUIDs related to lists and fields, and a working knowledge of Collaborative Application Markup Language (CAML). The Training Management Web forms, event receivers, and workflow business logic all require access to the Training Management lists. In the original version of the application, the list access logic was scattered throughout the application. To correct this problem, the application now centralizes the list access logic in repositories. Repositories simplify the access to list data and provide a layer of abstraction that makes unit testing with mock objects much easier.

For a discussion of the Repository pattern, see Repository on Martin Fowler's Web site.

The Service Locator Pattern

A service locator provides a centralized point for registering and looking up different objects. Service location is a useful way to hide the specific implementation of a service from the consumer of that service. For example, in the Training Management application, a Web Form may need to use a human resources (HR) management service, but it does not require information about how the service is implemented. It simply accesses an instance of that service. Service location is a common feature of dependency injection containers such as the Unity Application Block, the Castle Windsor Container, and the StructureMap dependency injection framework. The Training Management application implements a simple service locator, without the features of a full dependency injection container, such as cascading dependency resolution, lifetime management, and property/constructor injection.

The Training Management application uses the service locator to acquire services such as the repositories, the accounting manager, and the HR manager. For an example of how the application uses the service locator, see the CourseRegistrationPresenter.GetCourse method.

For a discussion of the Service Locator pattern, see the Service Locator Assembly topic in this guidance and Service Locator on MSDN. For information about the Unity Application Block, see Unity Application Block on MSDN. For information about the Castle Windsor container, see the Castle Project Web site. For information about StructureMap, see the SourceForge.NET Web site.

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

To provide feedback, get assistance, or download additional, please visit the SharePoint Guidance Community Web site.

Copyright © 2008 by Microsoft Corporation. All rights reserved.