R – Querying list items and using SharePoint web services vs the object model

Sure it is not the prettiest way of doing things, but it simply a matter of getting the correct examples.

I have used the following code to get "stuff" out of a get lists query.

public static XmlNodeList XpathQuery(XmlNode xmlToQuery, string xPathQuery)
{
    XmlDocument doc = new XmlDocument();
    doc.LoadXml(xmlToQuery.OuterXml);
    XmlNamespaceManager mg = new XmlNamespaceManager(doc.NameTable);
    mg.AddNamespace("sp", "http://schemas.microsoft.com/sharepoint/soap/");
    mg.AddNamespace("z", "#RowsetSchema");                                   
    mg.AddNamespace("rs", "urn:schemas-microsoft-com:rowset");
    mg.AddNamespace("y", "http://schemas.microsoft.com/sharepoint/soap/ois");
    mg.AddNamespace("w", "http://schemas.microsoft.com/WebPart/v2");
    mg.AddNamespace("d", "http://schemas.microsoft.com/sharepoint/soap/directory");
    return doc.SelectNodes(xPathQuery, mg);
}

Calling it using

    XmlNode items = lists.GetListItems(listName, string.Empty, listQuery, listViewFields, string.Empty, listQueryOptions, g.ToString());
    foreach (XmlNode listItem in SPCollection.XpathQuery(items, "//sp:listitems/rs:data/z:row"))
    {
        XmlAttribute id = listItem.Attributes["ows_Id"];
        if (id != null)
        {
            pageId = id.Value;                    
        }

    }

The example does not do a whole lot, but hopefully it gives you an idea of how to go about getting the data out. Yes I intensly dislike the whole namespace issue with XPathQueries, but what are you gonna do.

I am just not that interested in re-writing the SharePoint web services, especially as testing and releasing in our environment is weeks worth of effort in and of itself. Sometimes though, there is no option. E.g. if you want to access the custom property bag of an SPWeb or create a SiteCollection using a specific Site Template and content database (or any of the other million things that are not implemented in the web services). However, for simple list access, the webservices seem fine.

I agree with Greg in that I wouldn't necessarily recommend putting your data in SharePoint lists (this is what Greg may be assuming). But my short answer would be "maybe".

Here's the long answer...

SharePoint runs on ASP.NET so it should accommodate your needs. You would likely be writing ASP.NET web pages that live within SharePoint that access your database or writing web parts that live within SharePoint that access your database.

You could consider the BDC for reading/retrieving data, but that requires MOSS Enterprise and won't provide the CUD part of CRUD. Other tools like CorasWorks DIT may help, but I suspect that custom web parts or pages are the way to go for you.

There are plenty of benefits you can get from SharePoint such as authorization and maybe things like integration of your data with SharePoint list data, provisioning, search, etc. It really depends on the nature of your application as to whether SharePoint will provide much of a benefit.