Basic and Must use patterns for Sharepoint

Sep 13, 2009 at 4:06 AM

Hi,

I am working on sharepoint for quiet sometime, but never applied my hands on patterns.

Could anyone list basic and must use patterns list for sharepoint.

I have prepared a list of basic patterns, but not sure and would like to take opinion from experts of industry.

http://dotnetguts.blogspot.com/2009/09/patterns-and-practices-tutorial-for.html

Thanks everyone for participating on this thread.

Coordinator
Sep 14, 2009 at 9:51 PM

Hi,

Great question, I'd love to hear input on this as well.

We split patterns into design and application patterns.

Design Patterns

===========

For the patterns we covered in the guidance, many were motivated by maximizing unit testing, although they patterns are valuable as well for layering/separating concerns.  The two primary patterns that fall into this category are service locator and MVP.

Repository is a pattern I'd encourage many to consider.  It centralizes list access logic - and most performance bugs relate to list access, so reducing the amount of code you have related to list access is a good thing.  Also helps with centralizing policies, like caching.  We show both list repositories and respositories for LOB data.

Application Patterns

==============

These are higher level than design, and show how to solve a business problem in a reusable way using SharePoint.  We show three different app patterns for event driven site creation, site instance resolution, and event coordination (this is only a miminimal implemenation). 

THe scenario for these patterns was creating a site for collaboration on a business event (for example, a tier 3 incident, or an order exception).

 

I'm looking for input on the common, non-trivial customization scenarios that are often repeated.  Please feel free to email me any input for consideration in our next release!  (ckeyser@microsoft.com).

Chris

 

 

 

Jun 20, 2010 at 10:12 PM

Excellent thread.

" Repository is a pattern I'd encourage many to consider.  It centralizes list access logic - and most performance bugs relate to list access, so reducing the amount of code you have related to list access is a good thing.  "

I would agree with performance issues being related to Lists. I think this requires a section titled  "What Lists Do Not do" .  I feel the  SharePoint List is most always a victim of the "Square hole-Round peg" problem, and not so much that Lists are inferior things. that is to say people incorrectly implement them for the wrong reasons, and incorrectly use them once they are implemented.  

Id like to comment on your recommendation of the Repository Pattern.   Is this to suggest, using external storage, persistence , or other saving of objects instead of lists?  If so, whats an example implementation ?  

Further, does your recommendation of lists (performance and access concerns)  access apply to external lists as well?  

Thanks. 

Coordinator
Jun 21, 2010 at 12:32 PM

Hi,

The use of the repository pattern is not tied to type of persistence directly.  In general we will often use the repository pattern for both list and non-list data.  You definitely should the types of operations and whether lists are appropriate.  Lists are appropriate for simple data without complicated query requirements, and without transactional requirements.  We show in the guidance for 2007 (http://www.microsoft.com/spg) how to use the repository pattern accessing external services, and we ahve code examples.  In the guidance currently underway for 2010, we do look at external lists as well.   External data and lists have different limitations and considerations that need to be addressed.  Lists in SharePoint 2010 come closer to a database, and you can do things like cross-list queries more efficiently, as well as enforce parent-child and peer relationships with restrict delete or cascade delete.  However there still is not transactional support, and you there is a limit to the complexity of the types of queries that can be handled.  We talk about this in depth in the guide currently on codeplex which will release to MSDN next week.

Chris