How do I decide if an application is suitable for SharePoint?

Question

I'm currently looking at developing an application, and have a choice between doing a standard ASP.NET web application or integrating it into SharePoint. Our client would like it to be SharePoint if possible, as they are under pressure to put all new development into it, but standard ASP.NET is still an option.

It is an application to manage and view data in a database with about 10 tables, including an approval workflow when certain new items are added. Referential integrity of the data is important.

I have experience of developing ASP.NET applications, but very little with SharePoint. Does anyone have any criteria they would apply to deciding between the two?

So far I am thinking along the lines of:

• Referential integrity of the data is important and SP doesn't seem to handle this very well without writing lots of custom code
• SharePoint doesn't seem very scaleable with the suggested limit of 2000 items in a list
• The application has an approval workflow, which does seem to be something SP does well

On the wholem, it seems like we would end up writing lots of custom code and not really using any of the out of the box SP features. So my thinking is why not just write a standard ASP.NET application.

Are there any other key things we should consider?

Answer 1

You should also think about the complexity of deploying and updating your application on SharePoint.

Answer 2

Your evaluation is quite accurate. (It would help to have more detail about every feature your application needs but that's not really practical for this medium.)

The problems you mention have been largely solved but you would need to understand and implement the solutions. For example, there is a CodePlex project that can assist with referential integrity and there are recommendations on how to manage the number of items in a list. But using SharePoint is never going to give you the freedom of writing an ASP.NET application from scratch.

Another thing to consider is how you and/or the client expect the application will evolve in the future. If it will need more collaboration-style features or features such as version history on list items and integration with the Office client then SharePoint may be the better option.

Answer 3

By now, you may have already found this link: http://blogs.msdn.com/sanjaynarang/archive/2009/06/19/should-i-build-my-application-in-sharepoint-vs-asp-net.aspx. If not, it's a decent starting place with some good questions to ask.

What follows is my take as a long-time .NET developer (for as long as the platform has been around) and a SharePoint architect (since 2003). That's basically my way of saying that I've been on both sides of the fence.

In my opinion, SharePoint is a platform, not a product. As ASP.NET provides valuable web-based services to the core .NET framework, SharePoint supplies additional services and capabilities on top of ASP.NET. The platform removes the need for writing common code pieces that are a part of so many ASP.NET apps: security code, user profile management, personalization, UI/UX baseline, etc. When you get into the plumbing, you get even more: rich caching support that requires minimal configuration, customization modularity via Features, and more.

Should every application be built in SharePoint? I'd never push for that. With my current client, we use a mix of SharePoint-based and custom ASP.NET applications. Whether an application gets built in SharePoint vs. written from the ground-up in ASP.NET is a function of what we're doing. We conduct the same sort of exercise you are. If SharePoint's features and functionality can be brought to bear to reduce development time, it goes in SharePoint. If the need is too specific or we feel we'd be working around SharePoint, we go the custom app route.

You have some very specific concerns for your application, so let me take a crack at them with the little I understand about your requirements:

1. REFERENTIAL INTEGRITY: based on what you're saying, it sounds like your data model is pretty specific. Building your information architecture to natively leverage site columns, content types, and lists probably doesn't make sense. That doesn't throw SharePoint out, though. There's absolutely no reason why you couldn't build the data model you want (presumably in SQL Server) and then consume it with components that reside in SharePoint. If you're using MOSS, some of the BDC WebParts might work for you straightaway. If not, you'd still be writing controls and/or pages to work with the data, correct? There's nothing wrong with using SharePoint as your presentation layer for access to SQL directly or (in a more scalable, n-tier fashion) go against business services somewhere else.

2. 2000 ITEM LIMIT: this is a common concern and one that is misunderstood. There is no 2000 list item limit; the actual measurement is 2000 items per view (and that's with out of the box views, by the way) or "container" (such as a folder). You can store many more times that (millions, if you like) in a list if you partition with folders, build your own view to page, etc. Again, given your data structure and the likely need you have to dodge SharePoint's lists, this wouldn't be an issue if you simply consumed data from SQL Server.

3. WORKFLOW: SharePoint is nice as a workflow host, and the OOTB workflows are handy. I'm assuming you're looking at MOSS (versus straight WSS), but just in case: the approval workflow comes with MOSS. If you're constrained to WSS, you only have one workflow available to you: the three-state workflow.

At the end of the day, SharePoint is .NET and built on top of ASP.NET. Much of the code you'd have to write in a SharePoint app you'd need to write in a custom .NET anyway. I'd look at things from the perspective of understanding whether the experience and features SharePoint affords you (as a developer) can help speed your development cycle and/or improve the user experience (something we, as developers, sometimes forget).

David in Dakota does have an excellent point, though, in that the dev experience for SharePoint is different from straight ASP.NET. The need (or rather, best practice) to deploy via Features, understand specific SharePoint concerns (e.g., lifetime and disposal of SharePoint objects), etc., mean that there will be ramp-up time if you do build in SharePoint. There are quite a few good resources out there (including folks here on StackOverflow) that can help, but you'll need to factor some learning into the equation of whether or not SharePoint makes sense.

One more parting thought: Microsoft is slowly shifting many of its own products and platforms to leverage SharePoint as their UI/UX layer, and the trend is picking up some steam. PerformancePoint, Project Server, Team Foundation Server, and Commerce Server all use SharePoint as their presentation tier. The trend will probably continue, though I don't know how far. If you use any of these products (or their on your technology roadmap), a SharePoint investment now might pay off later.

Despite all of my writing about and advocating for SharePoint, I don't think it's the right tool in every scenario. I still build WinForms apps, smart clients, command line apps, and more quite a bit. It just comes down to weighing "what I get" for "what I spend" (in both time and money).

I hope this helps!