When to use application pages (aspx) versus web parts?

Question

I'm struggling with this question at the moment...

Basically I'm pulling a set of data out of a DB table related to our LOB application, listing it, and then want to click through from this list to another page detailing the selected entity. Say, as an example, I have Students. I want to list them on one page, and then clicking on a particular student takes you to a page for that student (where maybe you can edit the student, or click to view info about the Course they are on, Modules they have taken, etc..)

I was doing this in a web part, but then realized -- when I click on a student to go to another page, well, where do I go? Web parts don't really seem to fit the bill. So, would it make more sense to use aspx/ascx application pages here? They seem more suited to the idea of navigating around distinct parts of an application.

I found this page discussing the issues: http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages.aspx -- it seems like good advice, does it tally up with other people's experience?

Answer 1

My thoughts are these:

• The article is pretty consistent with my way of thinking
• If you're simply replacing a .net web app by a .net web app wrapped in a SharePoint masterpage then go the aspx/ascx approach. You gain little by forcing it into a webpart and just make your life more complicated.
  • This presumes that you do not desire any of the re-use or other capabilities that can be gained from using web parts
• If you want to leverage SharePoint features (i.e. bdc web part, connected web parts, configurable web parts) then I would consider leveraging SharePoint as appropriate

For your specific request, in SP2010 this could likely be met through the use of External Content Types & Lists. If that's an option I would pursue that approach first off. For 2007, it might be that BDC Metaman can help you and minimise the required effort.

Answer 2

The problem we most often face in SharePoint is having too many choices in how to do things.

The first question is site page versus application page. I tend to use application pages only for site maintenance and administration. I know they let you use code-behind, but I would try to avoid this - use a control or web part if you can, even in an application page. In fact the built-in pages to edit list items use a web part themselves. But I recommend using site pages if your end-users are going to be seeing them.

Second question - on the site page, which will be the target for your links, perhaps with a query string parameter; should I use a custom or user control or a web part? I would say that in SharePoint you might as well write a web part because it gives you all the extra plumbing for minimal extra effort. But you could do the job with a user control if you really wanted to. Note that the web part does not have to be in a web part zone, and can be embedded in the page in the same way as a regular control.

If you are using an external system, consider using BCS to expose this in SharePoint as an external list. You could then use something like XsltListViewWebPart on the page and possibly avoid custom code.

Depending on your business logic you might still want to build a custom web part. It is nice to build completely generic re-usable web parts, but this is not a necessity, and there is no reason to feel 'dirty' if you build a web part for a very specific purpose.