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.
Hi Marc,
I have been following you and your work for some time, but his the first time I have read the actual Manifestó.
Very clear and informative indeed.
To me, being more an admin with no development experience, it makes great sense to learn more about the skills and techniques to get things done in the middle tier.
I would like to know a little bit more about the aspects of deployments among differents enviroments.
What are your thougths on that?
Regards, Alejandro
Alejandro:
There are quite a few options on deployment, from simple copy and paste between SharePoint Designer instances to packaging up the results of the middle tier development in deployable features. The key is to decide what your process should be in your governance and then to decide how middle tier development fits into those rules. It may need to have slightly different rules, but it should conform to the overall ideas of your general governance.
M.
One thing Todd did touch on but I wanted to point out in more detail. SharePoint Designer is sold as an end user tool. It is for the “user” community, not developers. I have talked to many clients that misunderstand this and want a developer to create solutions using this tool. Doesn’t that defeat the whole purpose of purchasing SharePoint? Development effort is not always needed so to lessen the IT effort. In my opinion, SharePoint Designer should not be used by IT personnel. Otherwise, the client is not getting the full ROI from purchasing SharePoint.
Dan:
SharePoint Designer is both an end user tool *and* a developer tool. That’s one of the things that makes it so powerful. An end user can relatively easily do things like conditional formatting or format changes, but a developer (a Middle Tier developer – natch) can take it from there and customize further, if needed.
When you look at some of the capabilities in SharePoint Designer, like connecting to SQL data sources, it’s got to be a pretty savvy end user to take advantage of the capabilities. Microsoft’s view of a “user” is always a bit strangely skewed by their own experiences internally. They sometimes lose sight of what many real users are like, what their skill sets are, and what they *want* their skill sets to be. IMO, SharePoint Designer and other tools like Infopath can certainly be used by end users, but they will have to get up to speed on some fairly programmer-like skills to be effective.
M.