SP2010: some usefull notes
As promised, here are some of the notes I took at last weeks TechDays in The Netherlands. Some (perhaps even all) might already be known to you, but perhaps these help others to create better SharePoint solutions 🙂 I’m posting them as a little self reminder.
- In the object model, you frequently work with an SPWeb object. In particular, with the SPWeb.Lists property or SPList.Items to retrieve items from a list. One thing I didn’t know is that using these plural properties comes with a performance penalty, because the entire array is being loaded as soon as you use it in your code.
Example: web.Lists[“test”] won’t just get the “test” list, but will retrieve all lists! Same goes for list.Items.Count; this will load all list items, which is a big deal for large lists. So don’t do this and use methods like GetListByUrl or ItemCount instead!
- When working with subsites and lists, you’re code will often contain bits to combine URL’s. There’s a method you can use for this: SPUtility.ConcatUrls. I don’t exactly know what it does more then adding a forward slash in between two strings, but if you use it consequently it might help you when Microsoft decides to build URL’s differently in the next version of SharePoint.
- When you need to display a view of listitems on a page from code (for instance in a webpart); you can use SPListViewByQuery for this. Give it an SPQuery object and add it to the controls collection of your webpart, and SharePoint will render an entire listview. Nice and simple, but very powerfull!
- SharePoint stores some default info into default lists, like the User Information List. Getting those lists is quite easy by using SPSite.GetCatalog, which takes an enum and returns you the list you want.
- When you write custom solutions involving lists (for instance, a webpart which reads info from a custom list you’ve deployed); make sure you mark your lists as SEALED. You don’t want your user messing up your solution by accidentally deleting a column on which your solution is depending. This one might sound a bit “well duh”-ish, but I think I’ve never ever done this properly untill now.
- When you’re building solutions for farms which need to have a high percentage of availability, you need to consider a few things. For instance: deploying DLL’s to the GAC will always require a recycle of your app pool, thus downtime. So for high availability scenario’s; always deploy to the BIN instead.
The same goes for the usage of feature receivers. A solutions with a feature receiver is always being deployed to the GAC. Ergo: when using a feature receiver this will automatically mean downtime upon deployment of your solution, no matter what it does.
Hope these things help you just as much as they will help me!
Leave a Comment