SharePoint 2013 Web Parts And The App Model, Part 1: The Paradigm Shift

This is going to be a four part miniseries on SharePoint 2013 web parts. Here in part one, I'll philosophize about the new development paradigm and present an architecture that respects it while still giving us access to the functionality our web parts need. Parts two and three will dive into the details of this architecture for both the "server" (MVC) and "client" (Web Part) layers. Finally, I'll discuss the deployment bits needed to get all these pieces into place in part four.

As I get deeper and deeper into the new server-object-model-less SharePoint 2013 development approach, I find myself liking it more and more. Everything is more challenging without Microsoft.SharePoint.dll, which, after immersing myself in its various client side little brothers, almost seems like a crutch. SPContext.Current? Please. Child's play.

The point of avoiding the server object model (not just in web parts specifically, but everywhere) is not having custom code in the GAC, which Microsoft has identified as one of the major reasons people aren't upgrading their SharePoint farms. If you've been reading me over the years, you could imagine the pain and turmoil this caused me as an architect who approaches every problem with half a mind to "just build it from scratch." But I get it: if we move our SharePoint code out of SharePoint half way (by refactoring it into our MVC sites) or all the way (but blasting it into the cloud) we are keeping our environment pristine and in a more upgradable state.

Microsoft has given us the tools to accomplish this: beefing up the REST API as well as the C#, JavaScript, and Silverlight client object models, (CSOM, JSOM, and SLOM respectively) making front end developer's lives easier with the Design Manager, and of course having PowerShell as a first class citizen to script any deployment or administrative task you could dream of (if you indeed dream of such tasks).

But this new tool belt doesn't fit nearly as snugly as the server object model one did; there are holes in it. First off, the nearly 50MB of server side DLLs cast a rather large shadow over the two-ish megs down on the client. Of course, most of Microsoft.SharePoint.Client.Whatever's APIs are just wrapping service calls to their big brothers, but there's still a ton you can't do. A second hole is timer jobs. I loved using these babies to run code on a schedule, as SharePoint gives us a great platform of this.

But there's obviously no "client" equivalent to it. So we'll have to host our whateverOM in a service and point Task Scheduler at it. We lose our platform (specifically the ability to run our jobs on certain servers and have a nice administrative UI that even supports progress reporting). That sucks, but we can still certainly get the "job" done.

Thirdly, how does the concept of farm solutions fit into this new paradigm? On the one hand, it's a custom DLL in the GAC. But on the other, there doesn't necessarily need to be any SharePoint code in it. Think of it as a speed limit. On the highways feeding Chicago, the letter of the law says that you can't exceed 55 miles per hour (even though during rush hour you're lucky to get up to six or seven MPH, which is why I haven't had a car in almost ten years).

But the spirit of the law is to compel us to not operate our vehicles in an unsafe, borderline ballistic manner. Modern cars are safe at speeds of 80 and above, rendering 55 a boring jog to antilock brakes, weather-treated tires, and power steering. Driving at 56 miles per hour is technically illegal, but it criminalizes smart and attentive drivers whose cars were built after 1993.

That's how I'm approaching SharePoint 2013 WSPs. The letter of the law says no SharePoint code running in SharePoint. Fine. I'll give up my beloved server DLL. But I won't give up the ability to automatically package and deploy assets to all front ends of a SharePoint farm.

As I've worked my way through my first few projects in the new version, it turns out that web parts were the awkward square pegs that had to be pounded into SharePoint 2013's paradigm-shifting round holes. They fall right on the threshold of the old skool and the new skool approaches to SharePoint development. I'm reminded of a conversation I had with someone I was interviewing a few months back who had been involved in the 2013 beta. "No more web parts," he kept repeating, calmly. I didn't know if I should immediately terminate the interview for such blasphemy, or give him the job right on the spot for such foresight.

I think by "no more web parts" he meant "no more conventional web parts." Obviously, no more SharePoint code. But since the visual web part template in Visual Studio gives you a class that derives from System.Web.UI.WebControls.WebParts.WebPart, we're just dealing with harmless ASP.NET code. And since I cannot conceive of a SharePoint site with no web parts, this will have to do.

The right answer in 2013 is app parts. However, since they are rendered as iframes, they will not do for public-facing sites (which these initial projects were); we can't have a bunch of these guys confusing any spiders that want to crawl over our HTML. That said, we did use some for instances when all of the page functionality can be contained within the frame, and in locations that weren't as SEO-critical. But app parts aren't the major topic here; I want to explore the idea SharePoint 2013 visual web parts.

Like I said, we are dancing between SharePoint development paradigms old and new. The "old" aspect is the fact that we are using the visual web part template and deploying our web parts via WSPs. This way, they live in the web part gallery on the site collection, and can be dropped into web part zones on pages. But in the new, these web parts do not contain any references to Microsoft.SharePoint.dll, and operate, on the back end, completely within the app model.

In fact, as you'll see in part three, the only code beyond the class definition itself and the boilerplate initialization calls is logic I created to help facilitate passing web part property values to and from the CSOM living in our MVC app (which you'll be meeting in the next part). And since tool parts are gone ("gone" inasmuch as you can't do one without the server object model) these properties are limited to what the out of the box tool part can handle: essentially only static strings.

So these are technically web parts with code behind, but its only very basic configuration code; there's no procedural logic implemented within the web part itself, SharePoint or otherwise. It's interesting to note that given the new app model, visual web parts in 2013 have gotten some love. In SharePoint 2003, we had no UI at all. Then the SmartPart came out and duct taped an ASCX to our code. This got us through 2007, and in 2010, we were given this out of the box in Visual Studio with the inception of the "visual web part." However, it was still pretty much the same welding between HTML and C#.

Now in 2013, visual web parts finally behave like normal user controls: no more "web part" code behind file. We still have elements.xml and whatever.webpart files to configure the web part and its properties, but it's all one seamless package. In fact, the ASCX files are no longer served from _controltemplates; they are written into the DLL of the web part itself along with the rest of the logic (that's what that new whatever.ascx.g.cs Silverlight-y designer generated file is). This actually slows down front end development, since a CKS Dev (finally out for 2013!) "Copy to SharePoint Root" command is no longer available for web part ASCX files.

In recapitulation, before we get to the good stuff, the new 2013 app model has shaken things up quite a bit for SharePoint developers. In order to honor this and move all of our data access code out of SharePoint, visual web parts should no longer consume the server object model. However, we still need to take advantage of one of the fundamental aspects of a CMS: modular, pseudo-autonomous units of functionality can be plopped onto pages and "just work" within a certain context while not having to deal with iframes.

Part two will start to show us how it's done.