We all agree that SharePoint is a great application right out of the box, but is it more than that? Can SharePoint be used as a platform upon which we build web applications? The answer is most assuredly, YES. However, it’s not as cut and dried as we might like it to be. SharePoint has strengths and weaknesses that we must keep in mind. At times we may need to tweak our architecture a little to be able to take advantage of all that SharePoint offers. When does it make sense to do so, and when should we look elsewhere for a leg-up in our application building endeavors.
This post will begin to explore this scenario. It will not fully address every aspect, but it is a start. Future posts will continue to explore this thread, based on my own experience as well as comments left here and discussions I have with other developers.
One important point to make before going any further is that almost everything I cover in this post is available in SharePoint Foundation (SPF) – the free SKU (there are no server or client license costs for SPF). In some cases, I’ll talk about a capability of one of the SharePoint Server SKUs, but I’ll explicitly call those out. This means that you can use SPF and everything it gives you for no more than what it costs to buy ASP.Net – nothing.
To begin with, what are the common threads of most (if not all) web applications? What must any respectable web app include in order to be considered complete? A nice beginning list, in no particular order, would have to include:
- Security – who are you and what are you allowed to do? AuthN and AuthZ
- Data storage – a place for the stuff the app is responsible for managing
- Content presentation – showing that stuff in a usable manner
- Administration – Configuring the application
- User Interface – Outside of Content Presentation, above, this is the chrome of the app – navigation, graphics, interaction points, etc
- Performance enhancements/management – caching, etc.
- User management – adding, removing, editing users
I’m sure there are more but those represent a nice general-purpose list of what web applications do. Let’s take a look at these one at a time from a SharePoint perspective.
From an Authorization (AuthZ) perspective, SharePoint gives us a lot. It provides a whole collection of securable objects – from individual pages, to items to sites. In addition, it provides a collection of pages for managing security, assigning/revoking permissions, defining permission levels, managing group membership, etc), the concepts of roles and groups and a whole slew of other items. From an AuthN (authentication) perspective, SharePoint supports NTLM, Username/password and/or Claims based federated identity management out of the box. With little to no work, you can authenticate your users in whatever way makes the most sense for your application.
SharePoint provides a mechanism for storing data. Natively, it is not how most web applications store data, and perhaps not how most application architects “think” but it does store data. Instead of highly configurable relational tables, SharePoint stores rows and columns of data in lists. True, the structure of the database under the covers would make a DBA cringe, but we don’t deal with SharePoint data at that level. We remain higher up where the rows and columns analogy works pretty well.
With SharePoint 2010 you can get what I like to term “lightweight relations” between data points, but SharePoint is NOT a relational data store. I cannot emphasize that enough – SharePoint is not a relational data store. Don’t try to make it one. If you need relational data capabilities SharePoint is not the right place to store your data. That doesn’t mean, though, that SharePoint can’t present that data and allow users to interact with it. See the next section on Content Presentation for additional details on presenting external data.
From a purely “storing of data” point of view, SharePoint does it. You may need to rethink your data storage design and plans, but we’ll address that later.
SharePoint can present data to end users like any other web application. Similar to just about any web application, the actual storage location of that data is irrelevant – which is why I broke this out into two sections. SharePoint can present data and whether that data is stored inside SharePoint or elsewhere doesn’t matter. Presenting data stored in SharePoint is easy and there are a number of out of the box ways to do that – Views, Web Parts, etc. Presenting data stored externally to SharePoint is still no harder than in any other web application (just write the database access code like you would in ASP.Net, PHP, whatever) and could be much easier if you can use Business Connectivity Services (BCS), which is now mostly available in SPF.
Much of this is possible out-of-the-box with no custom code. If the out-of-the-box content presentation capabilities don’t suit your needs, then you need to write some code – but if you’re not using SharePoint and instead developing the application in ASP.NET, you’re writing code anyway, so you’re no worse off.
Any non-trivial application requires administration to one degree or another. SharePoint provides a framework for delivering that administration in the model that it utilizes itself – application pages (which are really just standard ASPX pages). In addition, SharePoint provides an easy mechanism for securing those pages to allow only administrators to access them (RequireSiteAdministrator).
Historically, SharePoint has been tarred with a reputation of delivering only “boxy” unfriendly user interfaces. All of that is over (beginning with 2007, but really coming into it’s own with 2010). Any UI you can deliver in ASP.NET, you can deliver in SharePoint. Period. End of story.
For anything but the most trivial of applications, performance is a concern. SharePoint provides some capability for cache management. For the most part, the actual caching is the same as what’s delivered in ASP.NET. SharePoint just adds a UI to allow you to administer the caching.
User management in SharePoint is primarily based around one of two areas – security and user information. Security is discussed above, and user information is handled via the User Profile Service (Server SKUs) or User Information List (SPF) of SharePoint. In either case, you have the means of managing information about your users that can be used as-is or enhanced (with or without code)
Additional Benefits of SharePoint
In addition to the above list of typical web applications elements, SharePoint provides a number of additional capabilities that can come in handy for some applications:
A fully baked Windows Workflow Foundation host to automate a business process
A built in process timer manager that can execute tasks on a defined schedule
A deployment management paradigm via Solution packages and Features
SharePoint Architectural Considerations
With all of that said, I don’t think there’s any doubt that SharePoint is a viable candidate for giving you a leg-up in your application building endeavors. However, like anything else, choosing SharePoint does require some trade-offs. Primarily I find that this comes into play in terms of interconnectedness. In other words SharePoint ties some things together that might not ordinarily be tied together. For example, when you define a Content Type, it has ramifications for the form used to present items of that Content Type. Sometimes this is a strength, sometimes it’s not. In addition, I try at all costs to avoid using some of the out-of-the-box columns that ship with SharePoint (like the ubiquitous Title column) as they just carry too much baggage. I find I’m far better off not using the default Title column and just creating my own.
SharePoint also has a tendency to force architectures down a certain path, that being a paradigm of multiple sites whereas a more traditional web application might be delivered in a single site. I reality, that’s just a semantic distinction. Sites in SharePoint are really just an organizational boundary and you don’t have to use multiple; you can often deliver everything within one site. In any case, your users never really need to know that they are visiting multiple sites. You can often hide it from all but the most observant of them (those that pay attention to URL strings).
Drawbacks of SharePoint as an App Platform
All is not perfect when using SharePoint as an app-platform, however. It does force you to rethink your applications somewhat and likely approach them in a new and different manner. In addition, SharePoint is a HUGE application and honestly some parts of it are better than others. In time, you get to know what parts to stay away from. Under the covers, there are some real head-scratchers and inconsistencies in the SharePoint object model. Again, you get to know SharePoint’s quirks as you work with it more. SharePoint also tends to lag about one release behind ASP.Net in access to the new things in the .NET Framework so if you find yourself constantly chasing those shiny objects, you’ll be forever tilting at the SharePoint windmill.
There are more drawbacks, and I’m sure each of you would come up with your own list. Honestly, I’ve been approaching SharePoint this way for so long that I forget what I use to rant and rave about. I look at what some of my ASP.Net friends have to do to build their applications and I just shake my head and say to myself – thank god I don’t have to deal with that anymore…
So that’s it. My take on SharePoint as an app-platform. Obviously I’m biased as I’ve already (mostly) made it over the hump and am comfortable with this model. I won’t say it was always an easy battle, but the end result has been well worth it.
What do you think?