harePoint is a powerful platform that gives you a very easy-to-setup place in which to put data. But you know what happens when you have a tool like SharePoint? People use it! And then, after people have put their data in, they want to retrieve it—in all sorts of weird ways. Putting in data is only half the story (and I'd argue, the easier part). It's fetching the data in a meaningful and targeted manner that separates the wheat from the chaff.
Business users can be amazing. They like to hit us with scenarios we could not have imagined in our wildest dreams, particularly after we thought we had all the requirements figured out. Much to my chagrin, I have heard the following, "Oh yeah, that is a new requirement!"
So it's important that developers' tools allow them the agility and flexibility to satisfy such needs and changing requirements.
At its heart, every system is basically data in and data out. Sure, standard adages apply, good architecture, garbage in, garbage out, etc. But SharePoint builds upon many years' experience, and thus includes a large number of features that developers otherwise would have to worry about or code from scratch. For example, SharePoint tracks every piece of content, keeping information such as when the information was submitted, who edited it last, and when they edited it. And just a few clicks away you can find even more information, such as versioning, content approval, and so on. But in addition to such tracking information, sometimes you need to fetch SharePoint data that may not be so straightforwardly available.
Retrieving SharePoint Data
There are several different options for pulling data out of SharePoint. For example, you can use the object model to get the SPList object, and run a for/each over its SPListItems collection. Of course, that isn't the smartest way to filter for data. Filtering via iteration can be extremely resource expensive.
You could search programmatically by using the FullTextSqlQuery object, as demonstrated in this article. That will provide you with quick results, but it may or may not provide you with accurate results, and this approach has an external dependency on crawl schedules and algorithms. Given the nature of search, you also have limited control over the sorting mechanisms. The sorting is controlled generally by the rank, which is dependent on an algorithm that you can influence, but not fully control.
And then you have CAML, the Collaborative Application Markup Language. SharePoint uses CAML for many purposes, one of which is extracting the data you need. CAML strikes an excellent balance between speed, dependability, and accuracy.
Within SharePoint you'll find a number of objects that use CAML and that can help you make data queries. This article looks at these objects individually.
The Lists Web Service
SharePoint ships with a number of pre-defined web services. Web services have the innate advantage of isolating atomic pieces of functionality, giving you better reliability and flexibility, a concept otherwise known as SOA (service oriented architecture).
Listing 1 shows an easy way to filter out all rows modified by a given user ID, using the lists.asmx web service.
Web services have their advantages, but performance and XmlSerialization isn't one of them, so it's reasonable to expect very rich support for CAML in the object model as well. At the heart of that you'll find the SPQuery object.
|Editor's Note: This article was first published in the May/June 2008 issue of CoDe Magazine, and is reprinted here by permission.|