Although I have been building custom applications on SharePoint Platform since MOSS 2007 days, when it comes to making decision on whether to use application page or site page features for specific scenario, I typically have to go through basics and try to weight pros and cons of each characteristics especially on coding complexity, runtime performance, future upgrade maintenance, deployment and retraction.
In past, I have time and time again relied on the Ted Pattison’s Chapter 2 and Chapter 3 of “Inside Microsoft Windows SharePoint Services 3.0” for decision making process on application vs. site pages. Typically it required me to go through both chapters and perform additional home work to review every aspect of application vs. site pages functionality. As you may understand, it has been tiring process. Over the time, I end up building my own list of major differences between site pages and application pages to help me making decision faster if it’s needed.
Generally my rule of thumb is to go for custom application pages for administrative tasks like maintenance or system pages and go for custom site pages for end-user business functionalities to promote end-user customizations if needed. Here are major characteristics and differences between site pages and application pages categorized by major areas of architectural decisions.
- An Application page is an ASP.NET content page hosted in the LAYOUTs directory on the WFEs and inherits from Microsoft.SharePoint.WebControls.LayoutsPageBase. Site Pages are stored in the virtual file system in the Content databases. SPFile and SPFolder objects represents Site Pages in WSS object model.
- As Name Suggest, An Application Page is application or farm scoped and A site page is site/web scoped.
- Site Pages consists of two compoents => Site Page Templates vs Site Page Instances
- Site Page Templates are .aspx pages stored in the file system in the FEATURES directory.
- Site Page Instances are provisioned through Module and File elements and resides in content database. They are created inside the context of the particular site. WSS treats Un-customized Site Page Instances as a reference pointer to the Site Page Template. You can use SharePoint Designer to customize or view site page instances. Both customized or un-customized site pages exposed through the virtual file system.
- An application page can have code behind and inline code but site page can’t have code behind or inline code. Using PageParserPaths for site pages is not best practice. Workaround for this problem is to create the site pages with web part pages and add web parts which has codebehind during feature activation.
- An application page doesn’t support editing web parts or web part zones (they are ghosted pages, you can add web parts and web part zones using code or declaratively but you can’t edit them through browser) but Site Pages supports editing web parts from browser. It means application pages would support only server controls, web parts, or user controls through code and cannot be personalized by end-users.
- An application page typically requires Visual Studio to customize the page, while Site Page can be easily customized through SharePoint Designer. First time you change the site page template or site page instance through SharePoint designer, it creates a customized copy and stores in the virtual file system. Use “Reset to Site Definition” to reset customized site page to the non-customized site page.
- An application page doesn’t support customization per site by site basis but site page supports different Site Pages per Site
- An application page is available to all the sites, while site page can be deployed only specific sites
- An application page is deployed in LAYOUTS directory when solution is deployed to the web application or farm, while site pages are deployed to content database when feature is activated for specific web. Site page templates gets deployed in FEATURES directory same way as application page when solution is deployed.
- An application page must requires a farm solution, while SitePage can be deployed using a sandbox solution. It means, application pages requires farm administrative privileges to deploy the changes while site pages can be deployed by site collection administrators/end-users.
- URL – An application page stored in the _layouts directory on each WFEs which would add “_layouts” in URL, while site page URLs can have fully customized business URLs. This can be go-no go decision with application pages in most cases.
- Performance – Because application pages are parsed and compiled as classic ASP.NET pages, they run faster than site pages. SPPageParserFilter parses and compiles the page into DLL. Customized Site Pages impact performance and scalability since they are rendered, runs in no-compile mode, and retrieved from the virtual file system.
- Maintaining or deploying updated Application page is much faster than maintaining Site Page because deployment method requires retracting/re-deploying site page on each site compare to application page on each application. This can be go-no go decision with site pages in thousands of sites deployment.
- Application pages are removed from the file system from the LAYOUTs folder when the solution is retracted but Site Pages requires Feature Receiver to delete the folder containing site pages in the content database during feature deactivation process. Site page templates gets retracted from FEATURES directory same way as application pages when solution is retracted.
- Chapter 2 and Chapter 3, Inside Microsoft Windows SharePoint Services 3.0, MS Press, Ted Pattison. This is still one of the best books on SharePoint and applicable to SharePoint 2010.
- Sahil Malik’s Apress Book – Microsoft SharePoint 2010 Building Solutions for SharePoint 2010, Jun 2010, Page 95. Sahil has demonstrated design pattern of how to build Site Pages with Web Parts to support code-behind in his book.
- Brilliant resource, Most complete I have found so far, App page vs Site pages => http://srisharepointdevelopment.blogspot.com/2011/07/app-page-vs-site-pages.html