SharePoint as a development platform
Any developer who has interacted with SharePoint in any way, shape or form will surely have asked themselves the question, asked someone else the question or read or partook in at least one of the many debates that have raged over the years. For me the question “is SharePoint a good development platform?” is pointlessly provocative so I would rather ask “can SharePoint be a good development platform?”. Instead of giving my own answer to that question I will quote Kirk Evans reflecting on a 6 part series of articles and screen casts he authored entitled SharePoint for Developers:
This series has been building up to an application that provides the ability for an end user to pause a video (rendered through a Silverlight media player) and capture annotations about the video at a particular time segment. You can imagine that, in a media company, there very well could be additional actions taken when someone creates an annotation such as automatically sending a formatted email to an advertiser (“The text formatting at time 00:00:28.4500000 does not comply with our standards for broadcast”). This is the real power and benefit of leveraging SharePoint as an application platform: we can incrementally add value to our solution without requiring us to build that functionality into the service. In a traditional ASP.NET application, you would likely add new functionality in a business logic layer, requiring a change in database storage, changes to the UI to display the new functionality, and changes to the service layer to expose the data to remote consumers. With SharePoint, you could simply attach workflows to the content type, and any updates to the list via our web service will enjoy this new functionality without making any changes to the web service. Or you might create a new content type and attach that to an existing list.
This is a hugely powerful concept, and strongly demonstrates why you should consider using SharePoint as a development platform. The separation of fields and content types and the ability to apply workflows to content types is huge. This separation provides the framework for reusable components that can be easily assembled by end users through the web UI instead of requiring developers to code more functionality. This lets you focus on creating the really cool building blocks and focusing on how to add value rather than writing monotonous forms code that performs CRUD operations against yet another custom database. It provides a single, consistent platform that provides the web UI, services, and storage within a single platform.
The possibilities here are staggering, because it truly changes the way we think about building applications.
I certainly do not want to reignite any of those previous flame wars about SharePoint as a development platform, I simply saw Kirk’s excellent work which clearly articulates how the development story around SharePoint is continuing to gather pace, credibility and substance.
Please; anyone wishing to express their views on this subject (for or against), I am happy to moderate comments from the well reasoned voices of experience but I have no inclination to host yet another flame war on the subject. I myself have struggled over the years with trying to build professional, robust systems on SharePoint but I would urge you to take the time to watch Kirk’s screen casts and read the wealth of information and resources he has taken considerable time to pull together. Nobody can deny the additional overheads (time, experience, software, hardware) involved and it boils down to whether those overheads outweigh the benefits that Kirk succinctly sums up and that can only be done on a person-by-person, situation-by-situation basis.
