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.

Comments

  • Anonymous
    March 25, 2005
    This is a GREAT explanation of SharePoint. I have been checking out your site for a while now and this latest entry, which provides one of the clearest explanations of what a SharePoint site is, has convinced me to link up your RSS feed to my community site for portals, collaboration, and multimedia. Kep up the great work!!
  • Anonymous
    April 05, 2005
    This is GREAT explanation Mike. However as you said it makes its very hard for developers and partners to build solution on top the sharepoint because of the whole GHOSTING pages as BLOB in database. Also in terms of performance I find it VERY VERY slow to render the page once its UNGHOSTED - SITE DEFINATION and other customization is fine but does not server full purpose of customization..
  • Anonymous
    June 05, 2005
    Did you ever post that comparison of SharePoint and DotNetNuke?

    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.
  • Anonymous
    August 12, 2005
    I can't say I'm a WSS or SPS expert, but after following sharepoint since V1.0 I've been repeating the mantra of EVERYTHING IS A LIST over and over andd it's helped me a great deal. Words of wisdom indeed. Thanks Mike!
  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/1993468-sps-directory-structure