Most Important Design Patterns for SharePoint Developers

A design pattern approach in SharePoint development is very important for standard and reusable solutions for most common problems in software development.

A design pattern approach in SharePoint development is very important for standard and reusable solutions for most common problems in software development. A design pattern is not only for implementation of code; it's solution template to solve real life Programmatic Problems. Adopting a design pattern approach to develop solution for SharePoint that allows you to formulate a high level Solution which is independent of the implementation details.
Most Common Design Patterns for SharePoint Development.

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

Model-View-Presenter (MVP)

As UI-creation technologies such as ASP.NET and Windows® Forms become more and more powerful, it's common practice to let the UI layer do more than it should. Without a clear separation of responsibilities, the UI layer can often become a catch-all for logic that really belongs in other layers of the application. One design pattern, the Model View Presenter (MVP) pattern, is especially well suited to solving this problem.

In SharePoint

A Web page or Web Part in a SharePoint application contains controls that display application data. A user can modify the data and submit the changes. The Web page or Web Part retrieves the data, handles user events, alters other controls on the page in response to the events, and submits the changed data. Including the code that performs these functions in the Web page or Web Part makes them complex, difficult to maintain, and hard to test.
Reference

Repository

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.
Mostly SharePoint applications, the business logic, access data from data stores such as SharePoint lists, or Web services. Directly accessing the data can result in the following:

• Duplicated code
• A higher potential for programming errors
• Weak typing of the business data
• Difficulty in centralizing data-related policies such as caching
• An inability to easily test the business logic in isolation from external dependencies

Use the Repository pattern to achieve one or more of the following objectives:

• You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
• You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
• You want to implement and centralize a caching strategy for the data source.
• You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
• You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
• You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
• You want to apply a domain model to simplify complex business logic.

Interactions of the repository

Interactions of a SharePoint list repository

Using the Repository pattern in a SharePoint application addresses several concerns.
SharePoint applications often store business information in SharePoint lists. To retrieve data from SharePoint lists requires careful use of the SharePoint API, knowledge of the GUIDs that are related to the lists and their fields, and a working knowledge of CAML. Repositories centralize this logic.
The amount of code that is required to query or update a SharePoint list item is enough to warrant its encapsulation into helper methods. When Web Forms, event receivers, and workflow business logic all require access to the same lists, the code that accesses the SharePoint lists can be duplicated throughout the application. This can make the application prone to bugs and difficult to maintain. Repositories eliminate this duplication.
Without a repository, the application is difficult to unit test because the business logic has direct dependencies on the SharePoint lists. Repositories centralize the access logic and provide a substitution point for the unit tests.

Components of a SharePoint list repository

Reference
http://msdn.microsoft.com/en-us/library/ff649690.aspx
http://msdn.microsoft.com/en-us/library/ff648864.aspx

Service Locator

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.

You have classes with dependencies on services whose concrete types are specified at compile time. In the following example, ClassA has compile time dependencies on ServiceA and ServiceB. The following diagram illustrates this.
This situation has the following drawbacks:
To replace or update the dependencies, you must change your classes' source code and recompile the solution.

• The concrete implementation of the dependencies must be available at compile time.
• Your classes are difficult to test in isolation because they have a direct reference to their dependencies. This means that these dependencies cannot be replaced with stubs or mock objects.
• Your classes contain repetitive code for creating, locating, and managing their dependencies.
• The next section describes how to address these issues.

Use the Service Locator pattern to achieve any of the following objectives:
You want to decouple your classes from their dependencies so that these dependencies can be replaced or updated with little or no change to the classes.
You want to write logic that depends on classes whose concrete implementation is not known at compile time.

• You want to be able to test your classes in isolation, without the dependencies.
• You do not want the logic that locates and manages the dependencies to be in your classes.
• You want to divide your application into loosely coupled modules that can be independently developed, tested, versioned, and deployed.

How classes use a service locator

http://msdn.microsoft.com/en-us/library/ff648968.aspx
http://msdn.microsoft.com/en-us/library/ff647944.aspx

The Trusted Façade Pattern

You want to authenticate external users that access a client application. Both the users and the application are outside the corporate firewall. The application is in the perimeter network (also known as DMZ, demilitarized zone, and screened subnet). It uses a Web service that is behind the firewall, in the corporate network. The application and the Web service also use different credential stores and authentication mechanisms. The following diagram shows the network topology.

Topology of the network

Use the Trusted Façade pattern with a SharePoint application to do the following:

• Authenticate external users of a SharePoint application that is located in a perimeter network. The SharePoint application uses a credential store that is also in the perimeter network.
• Authenticate the SharePoint application in a perimeter network to a Web service in the corporate network with credentials that are recognized in the corporate security domain.
• Ensure the confidentiality and integrity of messages that are exchanged between the SharePoint application and the Web service.
• Have a Web service in a corporate domain apply authorization rules that are based on the identity of the external user.
• Avoid creating additional credential stores to store passwords in the SharePoint application.

Trusted façade security layers

Reference
http://msdn.microsoft.com/en-us/library/ff649496.aspx