SharePoint 2010 Application Pages. vs. Web Parts

Question

I have done many a search on this issue with mixed results and ensuing ambiguity. The time has come to nail it down for good. If I'm developing the equivalent of a complex ASP.NET application, and I want to run it on top of SharePoint 2010, is it best to develop each page as a web part or an ASPX application page? The pages are many and varied, but each one interacts with a SQL 2008 R2 backend via custom WCF services.

I have yet to see a definitive and authoritative answer to this question. I'm looking for an official guideline from Microsoft or similar. I found this When to use application pages (aspx) versus web parts? on this site, but I'm looking to dig deeper with specific references. Here's a breakdown of what I have found so far:

The following non-official post would clearly favor application pages for my case. However, it was posted back in the MOSS 2007 days, when SharePoint development was more of a challenge. http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages.aspx

Microsoft, in comparing application pages to site pages, states, “An application page is the best type of page to create if you want the page to contain custom code.” http://msdn.microsoft.com/en-us/library/ee231581.aspx

So far, so good. But what threw me off was this other seemingly contradictory link, also from MS: "We currently recommend that third-party developers develop custom Web Parts, which can be added to site pages, to handle their solution's functionality whenever possible, rather than develop custom application pages.” (http://msdn.microsoft.com/en-us/library/gg552610.aspx)

I'm biased toward application pages because that's what our team has been using all along and has had no problems. Everything from the development experience to debugging and deployment support has been top notch. But internal forces are pushing for us to make the switch to web parts, so I'm looking for justification.

Answer 1

My general rule of thumb on application page versus web part is re-usabilty...i.e. do I need to surface the capability in more than one location within a site.

If I'm only going to surface a single instance of the functionality then surfacing that capability via an application page is the way to go because they are much easier to build, deploy, and maintain versus a web part...IMO anyway. The other challenge you have with web parts is they can be used in ways they were not intended to be used...i.e. you, as a developer, can't control what an admin does with the web part. It could be used in a context, with other web parts, that causes it or the other parts on the page not to work. An application page however has a singular purpose/function that can not easily be co-opted for another purpose/function.

That being said, if I have a current (...or perceive a future) requirement to leverage the functionality in multiple locations then it probably makes more sense to go the web part route, but that's not a hard and fast rule either. A recent example for me was a contact widget that the customer wanted displayed on multiple locations on the site. At first it seemed like a no-brainer for a little web part, but after digging into the requirements some more some on the team did not want to give up the real estate to surface it on all the necessary pages, so I ended up implementing it in an application page, dropping a button on the necessary site page, and popping up the contact form in a dialog.

Like most things SharePoint it's one of those "it depends" questions, but I think it's safe and probably prudent to start from a "I'm going to build an application page" position and see if there is an obvious rationale for moving away from that. The inverse of that doesn't make much sense to me.

Answer 2

One important thing is the performance aspect! Application pages are compiled when first accessed whereas site pages are not compiled.

Another important aspect is that Site Pages does only support controls marked as SafeControls and inline code is not possible (without fiddling with security).

Answer 3

I suppose the attraction of application pages is that they are much closer to being a "normal" aspx page. You say you are building what is, in effect, an aspx application on top of SharePoint. If this is a custom application that you do not anticipate re-using, and it doesn't need to be modular or modifiable by users, then maybe application pages are the best solution for you. Application pages can also be very efficient at runtime.

In general, and particularly for third party application developers (and I think this is probably the group that Microsoft's second quoted recommendation is aimed at), then web parts and site pages are the way to go for many reasons. Here's a few: composition, re-use, end-user configureable, potential use in the sandbox, no touching the filesystem.

Answer 4

I see mostly disadvantages with custom application pages when using these as content pages:

• Are accessible from all applications and sites in the farm (that may not be intended)
• Are not in the 'security context' of a site - you have to implement access control to these pages yourself (eventhough this is not a big deal)
• Are very unflexible
• Cannot be 'customized' out-of-the-box by users/administrators

I usually tend to create Visual WebParts using a Model View Presenter (MVP) pattern. This gives you a good code structure, better testability and enables you to use the WebPart in multiple places. Also you can expose a couple of options that users and/or administrators can set on the web part to change its behaviour. When building visual web part you have all the advantages that you have when creating custom application pages as there is full designer support.

An alternative for greater flexibility is to create user controls (ASCX) and place these i web parts and/or custom application pages.