There is a lot of discussion about whether SharePoint should be used as a platform to built applications upon. Some in favour - other strongly disagree - see flames/rants such as SharePoint is not a good development platform (do take a look at the comments which provide a broader view on this blogpost) - I did a discussion session at BIWUG today where we talked about some topics of which some are genuine pain points and others more likely rants. (Remark this are my personal remarks and not necessarily those of my employer ...) So here they come:
- The learning curve is quite steep. It is true that SharePoint requires quite a large set of development skills - .NET, ASP.NET, CSS, HTML, Javascript, SharePoint Object Model, Workflow Foundation, InfoPath, C#, Visual Studio,... But this is true for any web platform - web development hasn't reached the same level of maturity for developers as simple windows development.
- SharePoint is not documented or the documentation is not sufficient It is true that there are still some gaps in the SDK but Microsoft is working on this. V3 is actually better from a documentation standpoint then v2. Even in beta phases some documentation is already available. You have to take into account that the capability of the platform has enormously expanded. There is also a lot of information out there in newsgroups, blogs, etc ... make use of these. There is a vibrant SharePoint community out there with a lot of people which are really passionate about the technology. You might also take a look at SharePointPedia - which provides an aggregation of all SharePoint-related content on MSDN, blogs, forums, newsgroups, etc ...
- Why SharePoint if I can built it from scratch without SharePoint - Apparently there are not enough examples out there which show you how you can built something faster using the SharePoint collaboration framework. The samples in the SDK seems to focus on specific technical stuff in the Object Model. There is however not a lot of documentation about how you can do a translation of a business case to a SharePoint solution. The Fantastic 40 are however an excellent example of how this can be done - for an overview of the functionality implemented take a look at the Application Template datasheets.
- SharePoint is not for developers, it is an end-user tool - It is true that SharePoint provides a lot of value to your end users so that they can click their solutions together. But there is only so much that you can put in a framework and this is also the case for SharePoint. So even though there is a lot of out of the box functionality there is also a lot of room for extension.
- SharePoint has too much constraints - SharePoint is a product/framework with a number of standard functionality. The way that this is implemeted indeed poses some constraints for developers but it also gives you a lot of things that you can use in your projects such as out of the box security framework, navigation UI, personalization framework, etc ... I know that development in SharePoint v2 did not go that well due to the way that it was implemented. Since SharePoint V3 is implemented from the ground up with ASP.NET 2.0 - there are however a lot more possibilities. But I guess that SharePoint probably still suffers from the bad rep that it got with v2...
- You need to develop on Windows 2003/2008 - I don't see this as an issue (but maybe I'm spoiled) - virtualization is vastly improving and doing development in a virtual environment is doable. There are actually some interesting whitepapers about doing Team based SharePoint development in a virtual environment. A developer edition of WSS would be nice however ... also see SharePoint Server Developer Edition and Do SharePoint developers want a developer version of SharePoint? Apparently most of the BIWUG audience did not see this as much of an issue.
- Hard to debug, weird error messages and logging all over the place -The error messages are indeed quite cryptic but the logging is actually quite good. Next to the things which you find the eventlogs there also the SharePoint ULS logs. A lot is logged in the SharePoint ULS logs - and you have quite a lot of control on what is logged. The ULS logs are however quite hard to read - fortunately there is quite a nice tool out there which is called the ULS Log Viewer which you can download from the Codeplex Features project. Debugging is possible for code-based solutions such as webparts, workflows and event handlers. I would however love to see debugging support for features, content types and site definitions (or at least some more validation in Visual Studio). Sure you have WSS.XSD but it does not seem to be complete - but it provides basic intellisense in Visual Studio
- CAML :-) ... Yes, I know CAML (Collaborative Application Markup Language) is still out there just as Mike predicted. I don't think that we will see it disappear in SharePoint Vnext (this is a guess though). To make life easier - there a some tools out there to build CAML statements - my favourites U2U CAML Builder and Stramit's CAML builder. I would however love to have CAML designer support built into Visual Studio.
- Complex to build solutions - Yes you need to build SharePoint Solution files if you want to deploy your own customizations and normally you will need to use makecab.exe and create manifest.xml and a ddf file. Again the community comes to aid - the SharePoint WSP Builder is a must for every SharePoint developer. If you want to take it one step further you might take a look at the SharePoint Solution Installer which will convert your WSP file into an MSI.
- HTML Output is terrible - yes it is true, the standard SharePoint html output is not XHTML compliant. There are other issues as well with SharePoint with regards to accessibility such as the use of absolute font sizes in CSS files, etc ... So when this is a requirement, you will need to built your own master pages, css files (and for publishing sites your own page layouts). There is guidance available for building an accessible website in the form of the Accessibility Kit for SharePoint (AKS). The AKS contains sample master pages, css files and control adapters which you can take as an example.
- SharePoint does not support large lists and relational data - Again true, but SharePoint is not a database system (or not yet - see ...). So when this is an issue maybe SharePoint is not the right tool for solving your problem. Take a look at What not to store in SharePoint
- Lack of developer tools - Definitely take a look at VSeWSS (Visual Studio Extensions for WSS) - it has vastly improved in the 1.1 version. There are also a lot of community tools out there - I will post a list of must have SharePoint developer tools in the coming weeks.
- Poor data validation - SharePoint is a generic platform so all the validation is generically built. If you need specific data validation - you will probably need to write your own custom fields. Here you can add all the validation that you need.
So to summarize - for every issue/problem there is probably a workaround available out there. If I missed something, do not hesitate to add a comment. And if you attended the BIWUG session and you miss a link to a tool that I talked about - leave a comment as well :-) ...
Happy SharePointing
3 comments:
I think you are a bit off on what some of the issues with SharePoint are.
Why SharePoint if I can built it from scratch in SharePoint. -- The core issue here is "Why SharePoint if I can build it from scratch *faster*." A application or set of functionality has to be rich enough to justify the time spent implementing it using SharePoint. In my experience, this threshold is rarely reached and SharePoint is used to create a system that could have been built from the ground up faster.
SharePoint is not for developers, it is an end-user tool Whole-heartedly agree. It's an integrators/business user's tool. The fact that it is extensible doesn't mean you should extend it, and no one argues that it cannot be extended either.
SharePoint has too much constraints. The tradeoff between flexibility and out of the box functionality is too great for most developers to handle. Sharepoint development is too far abstracted from basic ASP.NET development. IMO, Microsoft needs to change the development model.
You need to develop on Windows 2003/2008. Yes, you are spoiled. Building and maintaining virtual images for development is a pain in the ass and adds overhead to your development process.
SharePoint does not support large lists and relational data
I feel this is a mis characterization. The real issue is that Sharepoint 'experts' are reccomending that you store relational data in a SharePoint list. This is a major problem. Relational Databases were built to handle issues that Sharepoint is re-introducing into the IT world. Eventually, DBAs everywhere will have to unwind the mess that many people have made with Sharepoint lists.
Lack of developer tools. VSeWSS does not work with VS.NET 2008. =|
Thanks for the feedback ...
I however do believe that in some cases it is faster to develop something in SharePoint then to build it from the ground up.
But as you said it is a thin line but when SharePoint matures it will become more obvious to start building on top of SharePoint then to start from scratch.
What do you mean with changing the develpment model?
The next version of VSEWSS (expected by summer) will support Visual Studio 2008...
By development model, I am talking about the recommended best practices from microsoft for doing SharePoint development.
It really is a mess. From developing within a VM, to the inability to store all development assets in a source controlled environment, to keeping all team member's development SharePoint environments properly synced. Team based SharePoint development is just more trouble than it is worth right now.
With all this being said, I do think SharePoint shows great potential as a platform for application development. However, I think tool support from Microsoft needs to improve significantly, and we need to have some better options for configuring SharePoint as well. For instance, I would prefer to see an option for SharePoint assets stored on the filesystem instead of in the database.
Post a Comment