SharePoint 2010 Genesis Framework – A framework that will help you create amazingly structured SharePoint solutions

Summary: SharePoint 2010 Genesis Framework is a framework that helps you declare fields, content types, lists and feature definitions through code. It also helps with provisioning and stronly typed data access.

One of SharePoints greatest strengths is its flexibility. Power users can easily create very powerful solution without much involvement of developers. In many cases though, custom development is needed for parts of a solution. In those cases, it’s very important to properly package the code together with the storage structures such as site columns, content types, lists, views and so on into a solution package.

However, doing this the “classic” way – defining the storage elements with CAML can cause some challenges both during the development phase and when the solution goes to application management. Most developers struggle with the following challenges:

• A lot of CAML/XML needs to be written
• It’s difficult to handle additions and changes to content types already in use
• No strongly typed access to SharePoint Data, unless you choose use LINQ-2-SharePoint

The new upgrade actions in SharePoint 2010 helps somewhat, but when working in an agile manner with deployments every 2-3 weeks, the XML can get really messy.

What many developers do is to manage most of the provisioning of content types, site columns, etc. with code and “ensure-style-features” that incrementally update the content types, lists, views, etc. This requires quite a lot of coding though, and many developers create their own helper classes that quickly evolve into “mini-frameworks”.

Tony Restaino, a senior SharePoint developer at Avega has been working on this issue for a while and have recently released an extensive framework to solve this issue – SharePoint 2010 Genesis Framework (SPGEN).

Tony and I have been working for a client on a two large SharePoint projects for a while now, and we have been using this framework to define content types, site columns, features, etc. and all the provisioning and data access. Want to add a new field to a content type? No problem – just create the field as a class, add it to the content type, rebuild and deploy the code, reactivate the feature and it’s there! The framework has also helped us implementing the repositories with with strongly typed data access in no time!

It’s just amazing how easy life gets with solutions like these! If only Microsoft could be just as thoughtful as Tony when developing the SharePoint API 🙂

A few of the key features of SPGEN:

  • It allows you to create classes that represent the different kind of elements in SharePoint – Site Columns, Content Types, List Instances, Views, Features etc.
  • You set attributes on the classes that correspond to the attributes of the SharePoint XML elements. This gives you strongly typed access to the definitions at any time!
  • The framework provides a lot of helper methods to provision fields, lists, views, etc. It automatically takes care of incremental updates, such as adding a new field to a list.
  • It also provides a way to easily create ListItem–object field mappers that maps list items to any class – no need to use the nasty auto generated mega classes from SPMetal!  You can even create your custom field adapters if you have custom columns that maps to complex data types.
  • It provides data access methods that allows you to do both CAML and LINQ queries against the lists, and returns the result as strongly typed objects.
  • It provides a LINQ implementation that has a LOT better performance the LINQ-2-SharePoint (at least according to our own measurements).

As you can see, it’s a very competent framework that can save a you lot of work – especially when developing custom code-based solutions. I strongly encourage everyone to check it out and give it a try!

Read more and download the framework here:

http://spgenesis.codeplex.com/

LINQ to SharePoint is not a substitute for a repository

LINQ to SharePoint is a nice new feature of SharePoint 2010, which offer both strongly typed access to SharePoint list data, as well as translation between LINQ and CAML queries. Even though this makes data access against lists a lot easier than before, there are a few things to keep in mind before deciding to use this in your solution.

First of all, LINQ to SharePoint is NOT a substitute for a repository. The SPMetal objects that are returned from the LINQ queries are basically just strongly typed representations of the list item objects. If you need change the structure of your list, you will have to update the SPMetal classes which will cause problems of you have a lot of dependencies to these classes in your code. Using LINQ to SharePoint directly from your UI components can lead to just as unmaintainable solutions as those built on LINQ to SQL.

A lot better option (see the image on the right side) is to create your own domain classes, create a mapping between your domain class and SPMetal class and encapsulate this together with the data access code in a repository. If anything changes in the list item structure, you will only need to update the mapper and SPMetal classes, nothing else.

Also, be aware that using LINQ to SharePoint may cause a performance overhead. We have done some simple performance measurement where we compare data access through LINQ with ‘classic’ style SPQuery. SPQuery actually performs a lot better. Two possible reasons are overhead in query translation from LINQ to CAML and the mapping between SPListItem and SPMetal object. Since the overhead is just as big when executing queries that return zero items, the query parsing and translation is the most likely cause of the performance penalty.

Of course, you can also still build your repository in the same manner as SharePoint Guidance for SharePoint 2007, with your own List Item mappers and CAML queries embedded in the repository.

There are a few options here, which is probably the best argument for building a repository that returns instances of your own domain classes rather than the SPMetal generated classes. If you do that, you are free to change the internal implementation and storage model without impacting the rest of your solution.