Loading tweets...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.
30 comments
21 pings
Skip to comment form ↓
Greg
April 15, 2010 at 10:16 am (UTC -4) Link to this comment
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.
Jim Lehmer
April 15, 2010 at 10:55 am (UTC -4) Link to this comment
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.
Danny
April 15, 2010 at 8:05 pm (UTC -4) Link to this comment
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.
Marc
April 15, 2010 at 8:14 pm (UTC -4) Link to this comment
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.
Danny
April 15, 2010 at 8:56 pm (UTC -4) Link to this comment
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 ?
Marc
April 15, 2010 at 10:46 pm (UTC -4) Link to this comment
Why yes, Danny, there will be plenty of Middle Tier coverage in my courses at USPJA. Be sure to tell all your friends!
M.
Jeremy Thake
April 17, 2010 at 1:28 am (UTC -4) Link to this comment
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
Todd C. Bleeker
April 19, 2010 at 3:07 am (UTC -4) Link to this comment
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.
Todd C. Bleeker
April 19, 2010 at 3:59 am (UTC -4) Link to this comment
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.
Marc
April 19, 2010 at 1:56 pm (UTC -4) Link to this comment
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.
Todd C. Bleeker
April 19, 2010 at 6:11 pm (UTC -4) Link to this comment
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.
Matt
April 19, 2010 at 9:27 am (UTC -4) Link to this comment
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.
Mike Oryszak
April 20, 2010 at 12:00 am (UTC -4) Link to this comment
Back in January there were some heated debates about the use of jQuery and whether it had any place in a solution provider’s toolkit. I wrote an article about SharePoint Dev and Customization Paths (http://nextconnect.blogspot.com/2010/01/sharepoint-dev-and-customization-paths.html) and I think it applies very well to this discussion. I believe in having options and applying the correct path for a given problem. Not every problem should be built with managed code, and in some cases or environments ad-hoc customizations are not appropriate. More than anything the architect needs to be educated in the decision points and needs to work to help educate the decision makers.
I have been in a few environments where there was a strict rule that there can be no server solutions. To me that is just as wrong as an environment that promotes a strict rule of no SharePoint Designer customizations.
Understand the problem, and select an appropriate solution. Don’t let your preferred approach dictate a solution.
David
April 21, 2010 at 9:18 am (UTC -4) Link to this comment
Hi Mark,
David in Japan here. (aka the bank you did work for). Been offline for a while as had another battle with cancer. Won this time as well. Have been catching up on all your work. Love the Middle Tier Manifesto as it addresses a number of good points with SharePoint that large orgs can have.
Can wait to get my teeth into your jquery library and give it a spin. cheers
d
Marc
April 21, 2010 at 9:32 am (UTC -4) Link to this comment
David:
Good to hear from you and that you are back in the saddle! I’ll be interested in your experience and take on SPServices. My experiences with “the bank” have informed my opinions in the Middle Tier Manifesto, for sure.
M.
1 2 Next »
The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint – An Early Response « Marc D Anderson's Blog
April 16, 2010 at 11:27 am (UTC -4) Link to this comment
[...] I felt that one particular exchange was worth reproducing here, if only so that I have easy access to it via a link. A gentlemen who calls himself “Jay” has caused a bit of a kerfluffle over at EndUserSharePoint.com over the last few days with his comments on Jason MacKenzie’s useful post jQuery vs Webparts solution. I’m assuming (I think reasonably) that it’s the same “Jay” who posted the comments below on my cross-post at EUSP of my original manifesto post. [...]
Marc D Anderson's Blog
April 17, 2010 at 1:23 am (UTC -4) Link to this comment
[...] The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint (see my prior post) has been garnering a decent amount of attention over the last few days, as I hoped it would. [...]
"Why Out-of-the-Box Makes No Sense in SharePoint" – A Rebuttal « Marc D Anderson's Blog
April 21, 2010 at 9:15 am (UTC -4) Link to this comment
[...] me and what Bjørn or Todd Bleeker et al would call "Developers" (see the comments here). I guess that some of my developer stripes may have washed off in the management consulting car [...]
XslLink vs. <xsl:import> in Data View Web Parts (DVWPs) « Marc D Anderson's Blog
April 21, 2010 at 10:33 pm (UTC -4) Link to this comment
[...] XSL Tags – Part 20 – <xsl:import>.) Probably because of my aproaching things from the Middle Tier, I just had never considered [...]
Only One SharePoint Virtual Machine Since Early 2007 « Marc D Anderson's Blog
May 4, 2010 at 12:05 pm (UTC -4) Link to this comment
[...] I do 90+% of my work with SharePoint in the Middle Tier, I’ve been using just one SharePoint 2007 (MOSS) virtual machine (VM) since early 2007. [...]
What is the Middle Tier? | sharepointsteven
May 18, 2010 at 11:54 pm (UTC -4) Link to this comment
[...] recently read “The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint” by Marc Anderson’s [...]
Is it Code? – A Rant, Response and Example of Social Media’s Reach « Nick Hadlee's Blog on SharePoint and Other Occasional Rants…
June 4, 2010 at 9:08 pm (UTC -4) Link to this comment
[...] effort put in Jim (@dullroar) and Raymond (@iwkid). Honourable mentions to Marc (@sympmarc) for his championing of the ‘middle-tier’ (oh brother flames and brimstone await me for the use of that term) and Mark (@mrackley) for [...]
Why Use DOM Manipulation Over Custom Code? « Marc D Anderson's Blog
August 25, 2010 at 1:20 pm (UTC -4) Link to this comment
[...] I discuss in my Middle Tier Manifesto, bad programming is bad programming. If you’ve hired contract .NET programmers and ended up [...]
A jQuery Library for SharePoint Web Services (WSS 3.0 and MOSS): Real World Example – Part 4 « Marc D Anderson's Blog
October 15, 2010 at 1:09 am (UTC -4) Link to this comment
[...] for stuff like this. If you want to use SharePoint to host real applications, develop them in the Middle Tier, and give them some real pizzazz, it’s something you might want to look [...]
A jQuery Library for SharePoint Web Services (WSS 3.0 and MOSS): Real World Example - Part 4 | EndUserSharePoint.com
October 18, 2010 at 10:01 am (UTC -4) Link to this comment
[...] for stuff like this. If you want to use SharePoint to host real applications, develop them in the Middle Tier, and give them some real pizzazz, it’s something you might want to look [...]
SPTechCon Boston 2010 – Recap and Accolades « Marc D Anderson's Blog
October 25, 2010 at 11:14 pm (UTC -4) Link to this comment
[...] well. Packed rooms either means that people thought I was giving something really cool away or that Middle Tier development is actually starting to get the attention it deserves. I’m going to go with the latter. [...]
Script in Content Editor Web Parts (CEWPs) in SharePoint 2010 « Marc D Anderson's Blog
October 26, 2010 at 12:32 pm (UTC -4) Link to this comment
[...] was a pretty big concern to me, the Middle Tier guy. After all, many people put their scripts into CEWPs for easy manipulation and management. I [...]
SPServices and SharePoint 2010 « Marc D Anderson's Blog
December 7, 2010 at 9:53 am (UTC -4) Link to this comment
[...] IT support. Working in the Middle Tier also means using more ubiquitous Web development tools (see: The Middle Tier Manifesto: An Alternative Approach to Development with Microsoft SharePoint) But if your team is made up of all hardcore .NET developers, then SPServices may not be for [...]
Memorable Moments from 2010…and What’s to Come in 2011 « Marc D Anderson's Blog
January 6, 2011 at 10:20 am (UTC -4) Link to this comment
[...] built a set of courses focused on what I see as the three key Middle Tier SharePoint development disciplines: Data View Web Part Basics, Enhancing the User Experience with jQuery, and Introduction [...]
Book Review: “Enterprise Application Development in SharePoint 2010” by Ira Fuchs « Marc D Anderson's Blog
April 1, 2011 at 11:56 am (UTC -4) Link to this comment
[...] book is an interestingly different take on what I call Middle Tier development. Ira uses the perhaps more correct term "declarative development" throughout his book, [...]
Problem with jQuery 1.7+ and SPServices » Marc D Anderson's Blog
November 15, 2011 at 6:03 am (UTC -4) Link to this comment
[...] issue I wrote about yesterday, may prove to be a big blow to those of us who choose to develop in SharePoint’s Middle Tier. As the standard bearer for this little movement, I can only do so much to make noise about how [...]
LINQ to SharePoint: The Good, the Bad, the Worse, the Ugly | Furuknap's SharePoint Corner
July 5, 2012 at 5:55 am (UTC -4) Link to this comment
[...] and especially third tier developers (meaning Visual Studio/.NET development following Marc D. Anderson’s Middle-Tier Manifesto), often manipulate data in some form or another. For a platform like SharePoint, that essentially [...]
I Am Not a .Net Developer |
August 9, 2012 at 8:43 pm (UTC -4) Link to this comment
[...] am definitely pleased with what I’ve been able to accomplish on the ‘middle tier,’ but I’m under no illusions that I’m the kind of developer who should be sinking [...]
Reading Guide: USP Journal Issues for SharePoint Third Tier Developers | Furuknap's SharePoint Corner
August 23, 2012 at 11:53 am (UTC -4) Link to this comment
[...] solutions for SharePoint. I recommend you read up on Marc Anderson’s Middle Tier Manifesto (http://sympmarc.com/2010/04/14/the-middle-tier-manifesto-an-alternative-approach-to-development-with… which will outline the tiers of SharePoint [...]
Become a SharePoint Professional (Series): Discipline | Furuknap's SharePoint Corner
December 16, 2012 at 11:47 am (UTC -4) Link to this comment
[...] within development, there are three ‘tiers’ of development (as defined in Marc Andersons Middle-Tier Manifesto), which broadly says which tools you use to accomplish your goals, and even within each of those [...]
What Is a SharePoint Developer?
January 2, 2013 at 7:49 am (UTC -4) Link to this comment
[...] Note: This tier division is the brain child of luminary Marc D. Anderson, detailed in his Middle-Tier Manifesto. [...]