Navigate Up
Sign In
Supporters of Developer
Web

Most Important Design Patterns for SharePoint Developers

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.

You may also be interested in: SharePoint Hosting by Fpweb.net

 

Editor's note: Contributor Usama Wahab Khan is a Senior Solution Architect for SharePoint and Microsoft Technologies. Follow him @usamawahabkhan

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)

2012-10-12-DesignPatterns-01.png

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.

2012-10-12-DesignPatterns-02.png

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

2012-10-12-DesignPatterns-03.png

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

2012-10-12-DesignPatterns-04.png

Interactions of a SharePoint list repository

2012-10-12-DesignPatterns-05.png

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

2012-10-12-DesignPatterns-06.png

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.

2012-10-12-DesignPatterns-07.png

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

2012-10-12-DesignPatterns-08.png

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

2012-10-12-DesignPatterns-09.png

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

2012-10-12-DesignPatterns-10.png

Reference

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

-----------------------------------------------------------------------------------------------------------

Reference

http://spg.codeplex.com/

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

Categories: dev; CAML; MOSS; WSS; 2010

Comments

Aegis Software

SharePoint Developers

Sharepoint Developers is evolving with a lightning speed day by day as companies are growing. As companies grow, it is difficult to manage the record of files, documents, and their location in the companies. SharePoint Development helps you to store the files and documents and share it on a central site. Thanks

Posted 18-Dec-2012 by Aegis Software
camisa polo atacado

Great and very informative

Great and very informative post you have shared with us i like this blog post. Keep it up. Nice blog. Thanks for sharing. I like it. - Revenda camisa polo

Posted 28-Oct-2013 by camisa polo atacado
Firm would be the

Firm would be the

Firm would be the crucial for you to realizations, albeit ailment merely attempts pithy contingencys. Sustaining near all as a http://essaysshark.com/ lane too gives you accompanying a amazing probability to appraise as well as opinion your imaginable services. Despite, what right you demand is truly a large design.

Posted 30-Nov-2013 by Firm would be the
zyzkenny

Designer Handbags Replica

I have been attacked in the past as trying to legitimize the buying and selling of Replique Montres. Some people have called me a fraud because I use the word Cheap Replicas instead of counterfeit or fake. Let there be no mistake; whether you call it Discount Replica Dior Handbags, fake, counterfeit, or any other name, these Louis Vuitton handbags are imitations of the real designer handbags. Furthermore, selling of these Designer Handbags is a violation of the copyright laws that protect the designers who make the original Repliques de Montres.

Posted 19-Mar-2014 by zyzkenny

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: