The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint
For some time now, I’ve felt the need to set down my thoughts on the power of development in the Middle Tier for SharePoint. Today, I’m publishing the first edition of my white paper The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint. I say ‘first edition’ because the days of spending a lot of money to print a white paper and distribute it widely are long gone. I expect to and want to develop these ideas over time based on input from you, the SharePoint community.
In this white paper, I lay out the methods and rationale for preferring to develop for SharePoint using SharePoint Designer and a combination of the Data View Web Part, scripting, and CSS over managed code. For quite a long time this is where I’ve focused my development efforts for clients and was part of the genesis for the jQuery Library for SharePoint Web Services (SPServices). I find that developing in the Middle Tier using SharePoint Designer can be faster, more reliable, and cheaper than the managed code approach.
I expect that some of you may well disagree with this premise and I know that others will absolutely agree with it; I welcome the debate. Take a read of the white paper and let me know what you think.
Thanks to Michael Greene (@webdes03) and Jim Bob Howard (@jbhoward) for their input on early drafts.
I am not well verse enough the technical aspects of it to comment on the pros and the cons but I found the paper to be really informative, weel structured and written paper.
Overall it’s a well-written paper that I think argues the points well. I am by nature a .NET developer, but as a lone wolf dev in a small shop, I try to use out-of-the-box SharePoint as much as possible, and Designer when I can (unfortunately, a lot of times what I have to do requires doing it across tens or hundreds of sites, so Designer doesn’t work so well for that – as you point out).
I had a few thoughts regarding specific points in the paper:
1) While XSL is indeed a “Web standard,” it is actually hard to find very many people well-versed in it. In my prior job I had to use it a lot, and finally had the epiphany of how to actually use it well (your series on DVWP and XSL has been informative and a good refresher). But when I interviewed some candidates a few years ago for a position here, NO ONE knew anything about it at all. I bring this up because of supportability issues – yes, YOU may be able to come in and deliver quickly, but I wonder how well a shop could then maintain it going forward without paying you to come back in and make XSL changes?
In general on this as well as CAML I blame MS in general because all of this should be supported by better tooling, as opposed to, “Here, go hand-hack all this XML.”
2) SP2010’s sandboxed solutions are sort of an “in-between” your middle tier and managed code tier now. Not that they aren’t in managed code, but because they are stored in the content DB, are administered by the site collection admin, not a farm admin, are limited in what they can do (and harm), etc.
3) VS2010’s new SP project types greatly reduce a lot of the complexity of developing SP managed code solutions by getting rid of a lot of the hand wiring that had to be done in the past, so the speed of development of a managed code solution is increased.
4) I am REALLY looking forward to using Designer with SP2010 for BCS/BDC models (they keep vacillating on naming). In the SP2010 class I had last week I was IMPRESSED with creating models in Designer (as compared to creating them by hand, which I have done in the past – see above comment about lack of tooling).
All in all a good, well-balanced discussion, Marc.
Marc,
It’s always good to have alternatives or options. At the end of the day, it’s what meets a clients needs. They are not concerned about what’s under the hood.
We as developers tend to get or be pidgeon holed – he’s a .net guy , she’s a vb.net person etc. I prefer to have many tools in my toolbox. This brief manifesto was well presented and provided a ‘thinking out of the box’ approach.
Several of Jim’s points are well taken. Maintenance is a big one. Using straight out of the box SharePoint is probably the safest bet. However , there might be instances where your middle
tier approach might come in handy. Perhaps some real world examples are in order, time permitting of course – looks like you’ve got a busy schedule.
Danny:
I’ve got lots of real world examples here in my blog and also over at EndUserSharePoint.com. If you want to focus just on a few articles, I’d suggest the three in the A jQuery Library for SharePoint Web Services (WSS 3.0 and MOSS): Real World Example series, but there are plenty more, from me and from many others.
You’re absolutely right that the whole point is to satisfy the business needs. None of what I’m talking about is because it’s more slick or elegant: I firmly believe that it can get the job done better and faster.
I tried to touch on some best practices in the white paper that can help to mitigate the maintenance concerns, but there’s always room for improvement. I don’t think that it’s usually the technology that makes things unmanageable, but the way it is used.
M.
Thanks for the information. I’d like to have a stronger grounding in SharePoint before exploring
the middle tier. Can I assume this subject will be included in the offerings at USPJA ?
Why yes, Danny, there will be plenty of Middle Tier coverage in my courses at USPJA. Be sure to tell all your friends!
M.
Good timing Marc, I’ve just put up a guidance technical paper on SharePoint Content & Application Lifecycle Management Guidance. This is great content mate!
http://wss.made4the.net/archive/2010/04/16/sharepoint-content-amp-application-lifecycle-management-guidance.aspx
I haven’t read thru your white paper yet but I have an issue with the term you are using for direct manipulation of content in the content database. That is not the “Middle Tier”. Officially, n-tier development consists of the Front End (user interface), the Middle Tier (business objects typically hosted for rapid, cached role-based retrieval), and the Back End (data store).
I would classify SharePoint Designer as a client application like Word, Excel, or PowerPoint as it manipulates docments in-situ. But it is certainly not the “Middle Tier”. I often characterize artifacts delivered in SharePoint Farm Solution Packages (WSPs) to the file system of a SharePoint farm’s Web Front End servers as “Infrastructure”. Infrastructure development is necessary for broad enterprise problems. When you find yourself copying that Master Page modification to all 20 locations – again, you have an enterprise need.
I’ll read thru your white paper and provide more detailed feedback as, on the face of it, I probably disagree with your conclusions. From the hip: Personalization and Customization have their place, but often they are used well beyond their intended boundaries. My simple rule of thumb has to do with likelihood of reuse. Simple, one off, get-er-done alterations should be done with the editor designed for that purpose. Changes that require multiple tweaks and may need to be changed in the future and potentially changed by someone else should have a more enterprise change approach.
First, let’s get the terms right…
What you are calling the First Tier = Browser
-SharePoint calls this Personalization and Administration
What you are calling the Middle Tier = SharePoint Designer
-SharePoint calls this Customization
What you are calling the Third Tier = Visual Studio
-Everyone in the world calls this Development
Redefining “development” is a bad idea. Words mean things. You don’t just get to assign your own meaning to well established phrases without causing chaos and confusion. People solely using SharePoint Designer are generally not developers. Period.
SharePoint Designer (SPD) is a Web designer’s tool for customizing content in the SharePoint content database, it is not suited for doing SharePoint development.
-You cannot create Web Parts.
-You cannot create Event Receivers.
-You cannot package a SharePoint Solution Package.
-Etc.
As powerful as jQuery is, it is a scripting language, not a compliable, imperative language. In fact, SPD cannot compile any language into an assembly. EVERYTHING that it does is declarative. In fact, if inline code is added to any context using SPD the browser will refuse to display the solution as “unsafe”. That’s because SPD is a content editor, not a developer IDE.
SPD is an editor designed for customizing the content in the SharePoint content database just like Word is an editor for customizing the content in a DOCX file and Excel is an editor for customizing the content in a XLSX file.
Just skimming your white paper, I think you are trying to say Customization has its place and .NET Development shouldn’t be the automatic first choice. I don’t think that is as controversial as you seem to imply. While SPD has its place, it is no substitute for a “managed code” enterprise solution when one is needed. I have a bigger beef with your misuse of standard terms like Middle Tier and Development than your position on the marginal and under-realized utility of SPD, the DVWP, and jQuery.
Remember, I was the first champion of “No Assembly Required” Content Editor Web Part solutions.
I am fond of saying that there are several things that developers _should_ be using SharePoint Designer to accomplish:
1. Do the things that can’t be done in the browser
2. Add and Customize List Forms
3. Add and Customize the Data View Web Parts and Data Form Web Parts (at least steal the auto-generated XSL)
4. Create declarative Workflows in-situ when possible, if needed on several lists use SPD to prototype the Workflow
5. Add and Customize Master Pages, Layout Pages, CSS, JavaScript, and the like for use in a single Site Collection; if a broader distribution is needed use SPD to prototype and then export to Visual Studio for inclusion in a SharePoint Solution Package (WSP)
6. *New: In 2010, Add and Customize BCS BDC Models (this is a no brainer IMO)
There may be some other XLV and XSL things that I’ll add in the 2010 timeframe. I can certainly see Adding and Customizing Content Types and Site Columns in SPD. But that isn’t hard to do in the browser either.
FWIW, I anticipate most of SPD’s functionality will be moved into the Web browser in vNext.
Todd:
First, thanks a lot for your responses. One of my goals with this white paper was to generate debate and discussion.
Another goal is to let “real” developers (or is it Developers?) know that there is this huge, unrecognized set of options available which enable you to build real solutions. No, they aren’t the answer to everything; nothing is. (SharePoint isn’t the answer to everything, either.)
Keep in mind that many organizations using SharePoint are not huge, global institutions with well-defined SDLCs. The best solutions for those guys are not necessarily the best solutions for smaller organizations, and they shouldn’t be considered as such.
I chose the “Middle Tier” moniker because I had to call it something. It sits in the middle between the UI and managed code, and it’s a higher level of effort than UI configuration, but usually less than managed code. I intentionally capitalized Middle Tier to try to name this middle space that people sometimes call Customization something else. It’s more important than Design (as in “SharePoint Designer”) or Customization, as you can do what I consider real development. No, not compiled code, but real development all the same. If the name is an issue (and you’re not the only one who has taken issue with it — some think it sounds too much like middleware — though most people haven’t), then I’m fine calling it “Bob” or “Strawberry Jam”. The name isn’t important; the fact that these methods and tools sit in this middle space and can provide real value is.
There’s a lot of discussion on the InterWebs about what type of development is “appropriate” with SharePoint, and the party line is generally “managed code in Visual Studio”. I’m trying to widen that answer, and I believe that it *is* controversial. I’ve worked with many clients where they have been told by Microsoft-certified developers that my “Middle Tier” approaches are evil and will cause their cats to go bald. It’s just not the case, and it’s a self-serving answer.
One last point: the jQuery part of this seems to be what more people are latching onto. I actually think that the more powerful piece is Data View Web Parts (DFWPs/DVWPs/XLVs, what have you). With DVWPs, you can build real forms and display content in myriad ways where you might be tempted to write managed code unecessarily. jQuery can further enhance the functionality on top of that, and can also certainly provide real functionality in its own right. To wit, my jQuery Library for SharePoint Web Services (SPServices).
Again, thanks for your thoughts. Let’s keep the dialog going.
M.
My biggest beef is with your use of the term “Middle Tier”, which already has a well-established meaning in a Web context.
I agree that the DVWP, DFWP, and the XLV Web Part have tons of power to “Customize” a SharePoint solution. I can confirm that fur bearing kittens will not go bald if declarative solutions are employed. Empowering end users to customize their individual SharePoint solutions in this way should continue to be encouraged.
I wouldn’t go as far as labeling SharePoint Customization “development”, but that’s not a hill I would die on. I do concede that a higher technical skillset is required to complete this kind of customization than most end user possess, but that doesn’t make it development. And we both know that some jQuery solutions are employed when a less brittle Farm Solution should be used instead.
But Marc, please rename your manifesto. SharePoint Designer is not the Middle Tier and calling the Middle Tier confuses the issue and dilutes your message.
Strikes me that what you are really talking about here is a “Middle Ground Manifesto” but even then there is plenty of room for debate over best tools for the job (and approach) in any given scenario.
In my experience the perceived need for a non-development approach often arises due to a lack of understanding of what an organisation are really taking on when SharePoint is the chosen platform. They are not prepared for the level of investment (time and resources) required to take the development approach and so cheaper/quicker (perceived) alternatives such as SPD and jQuery based solutions are sought. I’ve seen several other scenarios where these approaches are employed to great effect but IMO the grey area arises when one approach is used where the other is far more appropriate.