SharePoint
SharePoint can do a lot of things. But what's interesting is that each of these things in turn allows users to do a great many more things. SharePoint, when thinking about it architecturally, can be an out-of-the-box-install-and-tweak CMS; a document repository; an intranet; an extranet; a public website; an entire application platform.
So it's kind of a factory that manufactures factories.
Very rarely, in my experience, is the final product a site that people can immediately start using. Instead, the deliverable is the shell of a site; the potential for a site. We (the "SharePoint-y" folks) don't build houses; we build walls and bathrooms and kitchens and electrical systems and garages and landscapes. Our content authors, communications directors, CIO's, and IT professionals assemble the house from the raw materials we provide.
I think the main problem with the general paradigm of SharePoint development is that there's no general paradigm of SharePoint development. Each portal that needs to be built is done so pursuant to its own particulars. To continue the construction metaphors: there's more than one way to build a house; there's more than one way to build mansions, bungalows, apartment buildings, and Tiki huts as well.
However, there aren't too many different ways one could build, for example, a wall. Studs, a few sheets of drywall, and some screws more or less do the trick. Now of course there are a lot of ways that a wall can be decorated, but that's really outside the scope of its construction. It can be painted, wallpapered, adorned with pictures, and so on. This branding is specific to each wall of the house; the bare walls themselves should be built once and then rapidly cloned and assembled en mass. The same goes all the other components that will be welded together to frame the house.
Think of these walls, kitchens, and living rooms as SharePoint features, modules, and templates. In turn, we should think of ourselves as component builders. We're not building sites; that is what pure ASP.NET is for. This is SharePoint. We're building the components that, when wired together, implicitly comprise a portal or a CMS or really anything else you might see on the Internet. If these same exact components were assembled differently, we'd have a completely new portal.
Therefore one possible paradigm of SharePoint development is that we are component builders; we are control developers. There are two main differences between an application developer and a control developer. First of course is audience: while application developers build software for users, control developers build software for developers. The more specifically-skilled your audience is, the more precise your requirements will be. Consider yourself the audience for a control developer and someone like your mom the audience for an application developer.
The other difference is scope. Application developers build very specific sites that service a certain group of people or very specific apps that provide certain functionality. But the challenge for control developers is that the scope is much broader. Consider the textbox. Textboxes need to work in myriad different scenarios, across several different platforms (PC, Mac, web, desktop, mobile), support different languages, and so on...and after all that, they can be heavily customized (overhauled, even) by developers!
So we need to think of ourselves as control developers. Application developers are building software that has high-level "mom-like" requirements, such as "must be easily navigable" or "pages must load in two seconds." Control developers, instead, have to support features like "the data source must be configurable to any list that's associated with the News content type" or "must implement the IEnumerable interface."
Of course we can't lose sight of the overall vision of the portal. However, what's most important is that we build robust, reusable components that will work in all areas of the website. To continue with the example web part from the previous section, let's say we are now tasked with building it. Regardless of any other requirement, we need to ensure that this web part should be able to be dumped on any page in any site and either work implicitly or, worst case, fail gracefully.
It doesn't matter if it's on the root web or a sub web, the main site collection or an ancillary one, a publishing site or a team site, or any kind of layout page. Recall the SharePoint develop paradigm I described earlier: don't think of this task as creating a SharePoint site with a web part that consumes a list. Instead, understand that we are simply creating a web part.
We are not building houses. We are building walls.
However, (at the risk of bloating my metaphor) we do need to be aware of the house: you can't test a wall without one. The more specific our requirements, the more specifically we can create a "test" house for our wall. So what we really want to do is build the house without our wall, then throw the wall in, thoroughly test it in the house, and finally, when we're done, throw the house away, package our wall up, and start working on the roof.
How should this web part be built? Let me introduce SharePoint Deployment-Driven Design. This will of course be the overarching theme of the book, but for now I'll be abstract. The first thing we need to consider is not technically how the web part should be built; the primary question we should be asking is "What does this web part, whatever it is, need?"
Since this example web part consumes a list, we first need to ensure the list exists and understand the schema. So what does the list need? Probably a content type, a security context, and perhaps event receivers, extra site columns, views, and so on. Now in turn, what does the content type need? Its own site columns? Do those exist yet? And all these things live in a site, so we should probably make sure we provision one so as to not depend on being on the root site.
As you can probably follow, what we're doing is working backward to establish a task list that, when run through, ensures all the supporting pieces are in place before the web part has even a remote chance of working. So far, here's what we need (in order):
- Sub site
- Site columns
- List content type
- List
- Web part
What else? Web parts need to live on pages, so we need to know all the places it could be dropped. What do the pages need? Probably a page layout. And most likely a master page. Master pages need CSS files, JavaScript files, user controls, and other resources. Does our page layout or master page have code behind? Does this code behind reference other DLLs? Our task list grows:
- GAC'd DLLs
- CSS files
- JS files
- ASCX files
- Master page
- Page layout
- Instance of page
- Sub site
- Site columns
- List content type
- List
- Web part
Looking forward, before our web part can function on a site, what will it need? Since "postrequisite" is not a word, I'll have to coin it here. Whereas a data source or a configuration file might be a prerequisite or a dependency for a web part, a postrequisite is the safe control entry in the web.config. Or the .webpart file that needs to be uploaded to the gallery. Or default values for the web part's properties. Whereas prerequisites allow web parts to exist, postrequisites allow web parts to work. These come in at the end:
- GAC'd DLLs
- CSS files
- JS files
- ASCX files
- Master page
- Page layout
- Instance of page
- Sub site
- Site columns
- List content type
- List
- Web part
- Web.config modifications
- XML configuration files
- Default property values
And to come full circle, what about any environmental requirements? Certain features having been activated? The SharePoint Publishing infrastructure? And is this a farm solution? Sandbox? Let's finish off our tasks:
- Feature activation dependencies
- Solution package (WSP)
- GAC'd DLLs
- CSS files
- JS files
- ASCX files
- Master page
- Page layout
- Instance of page
- Sub site
- Site columns
- List content type
- List
- Web part
- Web.config modifications
- XML configuration files
- Default property values
As you can see, our little web part actually has over a dozen conceptual dependencies! And we haven't even considered what its core functionality is. There could be SPMetal objects to generate, databases to query, WCF endpoints to configure and consume, other web parts to connect to, as well as jQuery, images, resource files, etc. We'll talk about all these types of things later we when dive more into the minutia of SharePoint deployments.
For development purposes, we of course don't need all of them out of the gate. When testing the logic of the web part's code (and nothing else), we can get away with a vanilla out-of-the-box team site or publishing page. I don't want to add too much complexity or overhead to the development cycle, but as with any pattern, practice, or paradigm, some is unavoidable. Just keep in mind (and keep in your clients' minds) that the main value-add of Deployment Driven Design is time saved at the end of the project with a tiny investment at the beginning.
Now that we have these tasks all laid out, we can deploy our web part, and then start building it.
Yes, you read that correctly.
Like I said before: it does seem like a lot of overhead to provision an entire site collection to test a single web part. What about site templates? And why in the world would you spend any time at all on deployment before writing a single line of code against your requirements? And doesn't Visual Studio 2012 already do this? These are all valid questions. But perhaps the reason why so many SharePoint projects are delivered late, delivered over budget, or not delivered at all is because answers to questions like these aren't as obvious as they seem.
