Partager via

Should I Build my application in SharePoint vs. ASP.net

  • Article

Many times, I get question from my customers if they should build a new application in SharePoint or ASP.net. For certain kind of applications such as Collaboration or KM Portal, Internet facing web site, intranet social networking site, applications requiring browser enabled forms or Enterprise Search, SharePoint is THE option to go for.

However, it’s not a straight forward answer for all types of applications. You need to look at different aspects before deciding. I’ve put a high level list of questions that I use to make such decisions. Hopefully, the questions should help you also.

  1. What are the features that you are going to use out-of-the-box (OOB) from SharePoint (site provisioning, search, version control, roles/groups, easy forms (list edit, new, view pages), collaboration, workflows, content deployment, alerts ) )
    1. The list of feature is huge, have a look at evaluation guides for complete list: WSS, SharePoint and Search
    2. If you are not using any of these features what’s it that you’d gain from SharePoint?
    3. If you need these features, why are you thinking of not going with SharePoint? What’s the effort if you custom build those features?
  2. What are the features that I’m going to build custom (for example, reports for some applications would be custom and need relational tables with transactional support)
    1. How much effort is required for custom development in ASP.net vs. in SharePoint? Is the difference huge?
  3. What kind of application it is? Is it one off application, or this is going to replicated across many teams. SharePoint is an excellent platform where you need to replicate one type of site to many teams.
  4. What are the required Scale and Performance objectives of your application
    1. SharePoint has some boundaries, most of these can be avoided with adjusted design or workaround. Would the adjusted design or workaround be acceptable to your users? Examples:
      1. 2000 list items at a single level – a well know limitation
      2. 2000 security principles for a securable object – a lesser known limitation, but this can create problems when users in a site collection grows more than 2000 – there are workarounds for this (such as using AD security groups) – are those acceptable?
    2. SharePoint may not be able to match the performance of a plain ASP.net application as it does a lot more work (security trimming, getting files from database etc.) Can your performance targets be met using SharePoint?
      1. You can check benchmarks published by Microsoft or other vendors (such as HP, Intel) to see if SharePoint can meet your requirements. Links to most of the benchmarks are available in this blog post: SharePoint (Performance, Stress ) Load Testing 
  5. How many employees would be using these application? How many requests you can expect for customization from different teams. Remember, SharePoint provides a pretty good platform for customization and personalization.
  6. How much time do you have to build such apps? Can you use some off-the-shelf solutions? For examples, there are many custom applications which be deployed in no time by using WSS Application Templates (https://technet.microsoft.com/en-us/windowsserver/sharepoint/bb407286.aspx)
  7. What’s the cost you can afford. Remember, you need not buy any separate license, if you are only using Windows SharePoint Services. Have a look at difference of features between WSS and MOSS in the comparison Excel spreadsheet.
  8. What skills your developers have? Though SharePoint is based on ASP.net, but you need have additional knowledge to develop SharePoint applications. Also, development is SharePoint is not like normal .NET development (for example, you don’t get WYSWYG designer to develop web parts for SharePoint). You also need to take extra care to follow same build and source control process that you do for .Net code. Have a look at Application Lifecycle Management Resource Center for SharePoint Server for more details.

Comments

  • Anonymous
    June 22, 2009
    PingBack from http://stevepietrek.com/2009/06/22/links-6222009/

  • Anonymous
    June 28, 2009
    Nice article Sanjay, can you explain or point me to documenations about "2000 security principles for a securable object" limitation. Thanks.

  • Anonymous
    July 05, 2009
    Hi Toni, If you look at referred article Plan For Software Boundaries (http://technet.microsoft.com/en-us/library/cc262787.aspx) - you'll find more details on this. From that article: "The total size of the ACL on scopes can be no larger than 64kb. Because each security principal is approximately 32 bytes in size, there can be no more than approximately 2,000 security principals or less for each scope.  If this limit is reached, indexing of items in that scope, and all items below that scope, to fail. "

  • Anonymous
    July 12, 2009
    Sanjay, I am bit confused about "scope" here. It is not clear what is a scope... does this mean that I cannot have more than 2000 items with unique permissions or I cannot have more than 2000 custom permissions (e.g. users/groups) per item?

  • Anonymous
    July 20, 2009
    Article is very helpful if someone is new to the sharepoint and wants to develop application on MOSS 2007 Gr8 Snajay.

  • Anonymous
    July 21, 2009
    Toni - scope is any securable object. In SharePoint, it could be an item, a folder, a web or a site collection (this is the biggest scope that you can have). Sum total of all security principals (users/group) should not be more than 2000. Generally, you wont hit this limit for an item. But consider, you have item level permissions in a large site collection. Every user you add to a list item, also get added to site collection also (with limited access permission set). You need to ensure, unique users/groups across all items should not go beyond 2000. Hope this clarifies.

  • Anonymous
    April 01, 2010
    The comment has been removed

  • Anonymous
    April 21, 2010
    Hi This article addresses build in Sharepoint vs build traditional ASP.net apps. What are the considerations, and how would one approach the build in Sharepoint vs buy enterprise .net solution scenario. if an off the shelf package meets the business need (a .net + SQL db app), what is the motivation for building in Sharepoint? tx Em

  • Anonymous
    September 10, 2011
    Shrepoint is a document management system and a middle of the road one at best.  There are some advantages to build in sharepoint but not many AFAIC.  Share point is expensive, bloated and poorly performing.  I would never use it to build my corporate brain trust apps ever.  I think share point has lot of the "kool-aid" factor and far too many people have drunk up!.  Give aps.net, MVC, WCF, etc for al enterpise cash cow applications any day.