Discussing the ins and outs of developing for SharePoint and the Microsoft platform

This is one of those posts that is more my thoughts on how you could make use of something, so just run with me here and hopefully you’ll see what I mean! I travelled to Darwin recently and decided to use the time on the flight there and back to get my head around how LINQ to SharePoint will work with SharePoint 2010 – first of all let me just say that LINQ is awesome in general, and the implementation of it for SharePoint is seriously going to change the way you query for data in SharePoint sites (I love strongly typed objects!)

I’m not going to talk about specifically how to use LINQ in SharePoint 2010 here (although if you are in Canberra next week on Wednesday night be sure to come in to our SharePoint user group to see Alex Hobson from Unique World talk about this – I will hopefully have some video of the session to share afterwards as well). What I do want to talk about is how I think LINQ in SharePoint 2010 could work very, very sweetly with site definitions.

Using the tool SPMetal that comes with SharePoint 2010 (sits in the bin folder of the 14 hive) you can generate a code file that contains classes for your objects in a specific site. This will include a data context object, along with objects for all of your list level content types (all very strongly typed, I love it!). So each class file here essentially then represents a site within your site collection. Keep that bit in mind as we go on here.

When it comes to creating sites in SharePoint there are a couple of different schools of thought on the subject – there are the people that will do everything in features and just enable features on top of out of the box site definitions, there are people that use site definitions and put all of their logic into them (so they create lists, provision files, as much as they can get into that onet.cml file as possible) and then there are the people that take a bit of a hybrid approach in that they use site definitions that do no more than activate specific features to create the specific site types they need. I personally am a fan of the hybrid approach, and run all of my projects like this. Now you might be asking what this has to do with LINQ and I’m getting to that, just stay with me for a bit more.

So if you take an approach where you are using custom site definitions, you will likely end up with a few specific site configurations. Usually things like “Root site”, “Sub site”, “search site” and others will be on your list depending on what type of site you are putting together. Now go back to what I said about SPMetal generating a class file for a single site at a time and you might see what is in my head here. You could provide a solution that provided a site definition with various configurations, as well as a data context and types to query the data in your collection as part of the solution. So in your assembly SharePoint.Intranet.dll you could have namespaces set up like SharePoint.Intranet.SiteDefinitions.SubSite and SharePoint.Intranet.SiteDefinitions.RootSite and however many other configurations you had. The DLL for your main site definition that contains all of the features required to create your site now also contains a DLL with all the classes required to query the data within that site as well, you just use SPMetal to create a code file for each type of site you create definitions for, put them in appropriate namespaces and your done! Then you can use your sub site data context object to query any site that is based on your subsite definition (like INTRANET#1 or something like that) – there is essentially a very clear relationship between the type of the site and the data context you should use to query it.

Now I realise that for anyone who has been playing with LINQ already, in particular the SharePoint 2010 stuff this idea might seem somewhat old, but seeing as I’m relatively new to both counts this I think this idea is really cool, and I definitely plan on using it when I get into some SharePoint 2010 work!