SharePoint Sites are Data
Next week I’m going to post something that explains the relative merits of efforts like IBuySpy Portal, DotNetNuke, etc., compared to Windows SharePoint Services and SharePoint Portal Server. We’re getting asked that question a lot. We also get asked the question as to why it seems to be so hard to move a SharePoint site from a build environment to a test environment and on to a deployment environment (we’re working on that, by the way). In order to answer those questions (and others), I’d need to begin with the following statement, so I’ll expand upon it now so I can cite it when I need it:
SharePoint sites are data. Not application code. Data.
Yes, you’d be tempted to regard a site as what you see before your eyes: a Web site application that’s built with ASP.NET pages, ASP.NET Web services, etc. But I’m not talking (sic) about user experience, I’m talking (sic) about architecture. Lacking an easy way to embed a diagram, I’ll do my best to paint a picture of what’s going on using words…
A SharePoint site, at its core, is a set of lists. Document libraries, users, event calendars, surveys, tasks, discussions, Web Part galleries, template galleries — they’re all lists. Even the instancing of Web Parts on specific pages in a site (zones, properties, etc.) is effectively a list. For every list, we store data and meta data, including views.
The set of sites/lists are maintained in SQL Server. Access to SQL Server is constrained to stored procedures. Access to those stored procedures happens via ISAPI (for WebDAV, FrontPage RPCs, and static HTTP GETs) or via a managed API. We call that managed API ourselves, inside ASP.NET-authored SOAP Web services, as well as by our ASP.NET-based Dynamic HTML interface.
Architecturally, the DHTML interface we provide via ASP.NET is really just one way of getting to a SharePoint site. A nice way. An important way. A way to which we’ve devoted a lot of work and to which we continue to devote a lot of work. A way you can extend with Web Parts to pull in non-site data or new views of site data. But ultimately, it’s not the star of the show, but rather a much-loved supporting cast member.
How do we deliver the DHTML interface? For each site, and for each list, there are database-defined ways to render it (e.g., EditItem,AddItem,ViewList), and for each one, we effectively store the location the ASP.NET page used to do that rendering in the database. Those pages are usually stored in localized resource directories on the Web server’s file system, but if you edited a page in FrontPage, we store the edited page directly in the database itself as a BLOB.
It’s only at this point that Web Parts enter the picture. Those ASP.NET pages involve extra code to provide the infrastructure for hosting Web Parts.
And to bring it all back to lists (i.e., data), the most important Web Part we provide in the box is the ListView Web Part, whose job it is to grab a list’s CAML XML data and view rendering meta data and apply the latter to the former to generate HTML. It’s much, much, much faster than iterating through object model collections in loops and building up the HTML that way. Every time you create a list, we add an instance of the ListView Web Part preset to point to that list into the site’s Web Part Gallery. It is, however, one piece of code we use over and over and over again to render every list in every site.
This architecture is what enables the scalability, availability, manageability, and extensibility of the WSS platform. It has a few costs, but many more benefits. More on this next week.