SharePoint - The New Oracle
I was posting a WPF question on stackoverflow and I took a few minutes to tie up loose ends on a question I had asked back in September about how to best go about developing web parts for SharePoint as an ASP.NET developer. I was just getting started out with rough proto-types of what the client was requesting and was doing all my mock-ups in ASP.NET web forms. I didn't want to be "slowed down" by any SharePoint learning curve. I was comfortable in ASP.NET and just wanted to be able to deploy my ASP.NET user controls into SharePoint and not get my hands dirty actually learning SharePoint. I asked the question hoping for a quick work-around that would fit my needs. So here I am 3 months later, a SharePoint survivor. Question is: would I start the same way if I had it to do again?
Not a chance!
Disclaimer: To be honest, I did get some good responses to my question with suggestions on work-around's that are available such as web parts that have been written to host ASP.NET user controls. Also, I was informed that you can actually deploy both user controls and even full ASP.NET pages to the SharePoint hive (folder structure where disk-based SharePoint resources are stored) and they just work, though your access to the SharePoint object model will be limited. These are viable options that will get you up and running fairly quickly. However, in my brief experience, it is not the way I would choose to go.
The problem with SharePoint, in my jaded opinion, is that it is too easy. In fact it could be called the new Access. You can read some articles, follow a few tutorials, point and click your way to version 1.0 of your internal HR site and call yourself a SharePoint Developer. Yes, SharePoint is definitely easy....at first. However, that doesn't cut it in the long run and you should be very afraid of version 2.0 when it comes along. It is easy to install a new blog or department calendar, set up a page for HR to start uploading files and photos of the company picnic. That's all well and good, but we are not talking about out-of-the-box web parts here. Now we've moved on to custom web parts that need to be built from scratch and be robust, secure and user friendly. This is when we hit it, the SharePoint learning curve, more like a wall really, or a cliff with a whole pile of bleached bones at the base. Fact is, if you are a serious developer, you are going to hit this wall sooner or later. The last 20% always gets you when you are working with a platform that is designed to make it all "easy". That being the case, make the conscious decision to hit the wall sooner. If you put off the "learning wall of despair" too long, it will hit when you at a point in your timeline when you can't afford any unpredictable delays. Others, and even you, may think you are "done" ("it's all coded we just need to deploy it and we're good"). For some reason project managers and stakeholders take issue when "done" turns into a 3-6 week delay as you come up to speed with all the goodness that is SharePoint deployment. So, when starting on your first SharePoint project, dive in, the waters tepid! In the long term you, and your project will be better for it.
As a side point, a comment on the value of having SharePoint as a skill in your toolbox:
SharePoint will never be my choice of a application platform to work with. However life, as it turns out, is not all about what we want. Who would've thunk it? All that being said, it is a skill and it is not an easy one to acquire an expert level understanding of. I think a more accurate label for SharePoint, as the blog title indicates, is the new Oracle, in that it is hard, complex, has an almost a complete lack of effective tooling, is about as developer friendly as wet punch cards, and the majority of developers who claim to have SP skilz, couldn't code their way out of a cardboard web part. Call me cynical, but I think it's a fairly accurate assessment. Match that situation with a high client demand for SharePoint development and you have, in my opinion, a technology worthy of black turtlenecks and designer level salaries. So I guess this post proves you can find a silver lining in any technology. :-)
If you are faced with a SharePoint learning wall, grab the opportunity and learn it well. Don't become another SharePoint/Access developer.
Here are some links that helped me get up to speed.
- Heather Solomon's Blog about branding your SharePoint site
- TheKid posts a SharePoint deployment project template on CodePlex
- it is C#, but is easily convertible to VB.NET as well
- there is a bit of a learning curve with this as well, but it will prove to be much more stable then then WSS extensions method that the MSDN docs would have you using. You will learn to love the command line again!
- The WSE extensions in Visual Studio are the "documented" way of developing SP projects, but, from my experience, it will leave you only part way there, and you won't learn about what is happening under the hood and won't have as good of an idea when something breaks.
- Understanding deployment is vital to maintaining sanity.
- Related to deployment as well the Microsoft documentation on using the stsadm.exe command line tool to deploy and upgrade your SharePoint projects
- How to wire up AJAX in your SharePoint web parts
- Addressing potential confusion over when SPWeb and SPSite objects should be disposed of:
- CAML query builder for querying SharePoint lists
- Blog about displaying custom data in a SPGrid
- Of course the MSDN docs on the object model and some performance considerations
© Copyright 2009 - Andreas Zenker