Sharepoint 2010 web application development suitability evaluation/assessment

Question

I would like to know what kind of applications are suitable to be developed on top of Sharepoint 2010 and which should not be built on to of it. So when to embrace/avoid Sharepoint 2010 as a development platform for new web applications.

Addendum

Would you as a sharepoint development specialist choose it as a platform for your next enterprise application with these characteristics:

• processor intensive
• lots of various screens for entering and managing data
• many complex business processes
• no need to change the UI (ie. reposition parts)
• ERP integration
• etc.

I'm an Asp.net MVC (former web forms) developer and would like to know if usual multi-page semi complex web applications (intra/extra-net) should be built on top of Sharepoint 2010 and why (if yes or if no).

Answer 1

I will preface this by saying that sharepoint is a usability, development and performance nightmare. I've met few users who enjoy it, the dev approach to create robust solutions is like juggling bowling pins while log-rolling and there is so much extra bloat in the framework that building a high-performance solution in it is almost impossible.

Despite this, it's very good for building intranet solutions like dashboards that tap into line of business systems. You can do quite a bit in it without ever having to write actual code, so team rooms and basic data collection activities are a good fit.

What I wouldn't build on it is a public-facing company website that is either static or provides a service.

Answer 2

Its a steep learning curve and Sharepoint 2007 didnt help out much. You either had to tweak what came out the box or do a lot of work to get a useable environemnt (read blank master pages, controls and layouts that supported xhtml, jquery support etc)

If you have a system that is document or image rich, or your customer has the need for a typical out of the box extranet/intranet in a hurry then it is a good tool.

Otherwise its a lot of effort to get up to speed that may not be worth it.

EDIT: Asp.net as a default setting. It depends if you need a portal/content management/document and image sharing. If you are jsut creating bespoke applications you jsut dont need it. If you are creating a community with resource/document sharing, then Sharepoints the way to go. You can still do ASP.NET inside Sharepoint - thats what it is built on.

Answer 3

The development tools for SharePoint have improved a lot in the 2010 version. If you know ASP.NET MVC but not SharePoint, you'll probably get your application done faster in MVC, but the question is what will happen to it afterwards. SharePoint makes it easy to make applications that non-developers can modify later in some way.

For instance, you can:

• Make parts of your application available as web parts, which users and administrators can place where they want
• Deliver your application as a SharePoint solution, allowing administrators to deploy it within some other context, such as an intranet site
• Allow power users to edit forms with SharePoint Designer or InfoPath
• Integrate with the collaboration functionality in SharePoint, such as document workspaces

On the other hand, SharePoint gives you lots of stuff that may just be in the way, (there's a ton of databases, IIS sites, services, etc.), and you may have to work harder to achieve the same level of visual and functional control over your application as you would in MVC. And unit testing is pretty hard.

So basically it's a question of how flexible you want the application to be, and at what level. I wouldn't use SharePoint 2010 for everything. This site - Stack Overflow - is an example of an application where SharePoint would just be in the way.

To answer your other question, though, I don't have any very strong arguments not to use it, if that's what your client wants, (apart from that it will take longer, because you'll have to learn SharePoint). And considering that SharePoint 2010 is pretty fun to work with, I'd take the excuse to get to know it. Then you'll be better able to argue for and against it in the future.