Web Part vs using Application pages

As a developer we have many options available to us and it is difficult at first to really understand where to use what and when to use it. Hopefully through my trials and errors I will be able to share with you what I have found works best.

SharePoint opportunities as a developer

SharePoint, WSS 3.0 leverages on top of the .NET 2.0 and 3.0 frameworks using many ASP.NET features to deliver a powerful portal engine. As an ASP.NET developer there are many different approaches to develop a web site and how to go about it. The trick with SharePoint development is to know when to use what. What makes it a bit more confusing is that many ASP.NET developers are introduced features of the .NET framework that they never new existed and the combination of the two new technologies becomes quite confusing. There is however one thing in common, however or whatever approach you take, you will be generating HTML, CSS and client side scripts.

Web Parts

Web Parts are really nice server side controls that give the user the following benefits

  • Personalisation
    • a user can move the control to different zones on the page.
    • a user can customise settings of a web part allowing data to be filtered, selected or rendered by parameters
    • a user can choose to put a web part on a page or not.
  • Reusability
    • Web parts are intended to be reused on many different site pages
  • Communication
    • Web Parts can communicate with other web parts on the same page, sharing information between the controls providing a master / detail set of controls
  • Summaries and information sharing

Web parts are intended to be used to display summarised and management information to users in a dashboard type page. This page should have web parts that show results, graphs, KPI’s and keep with the spirit of a SharePoint site … that is to share and make information visible and easily accessible. The primary goal is to. The idea of a web part has been confusing to many, and often web parts are created for the wrong reasons, these include

  • data capture and entry
  • one-of-a-kind web part that will be placed on a site page by an administrator and will only be used once.
  • front-end controls for line of business applications.

After all, a user is not going to want to choose the location on the screen to where to capture the new account details for a new customer, nor will they choose to optionally display or hide this from their screen.

Site Pages

Site pages are aspx pages that have web part zones in them, allowing a user \ administrator to choose a web part and drop it into a zone. A site page should not need to have code behind the page and most definitely should not be hard wired to interact with a specific web part. In essence it as a template for a page that contains zones. These zones will be filled with web parts. Please do not put code into your site pages or hard wire the site pages.

Application Pages

Application pages are for all intense purposes the same as a traditional .aspx page where you can do what ever on the page you wish. Application pages are ideal for your line of business pages and data capture pages. Your application page can also contain as much code and complexity as you like. You can choose to interact with SharePoint or do your own thing. Application pages should be used for

  • Data capture pages
  • Line of business or system pages
  • Configuration pages
  • Pages that are a one-of-a kind page
  • Pages that should not be customised by users
  • Requires code behind the page

Now, another small mistake that many developers make is that they place complex logic into the .aspx page, instead get used to putting your logic into an .asxc page and then dropping this onto your page.


Create application pages for you line of business systems and implement these into your solution. Threat these application pages as you would a traditional ASP.NET web site, however you need to play by a few Windows SharePoint Services rules. Don’t use web parts for this as it is pointless and far too much work (and pain). Create links from the navigation system of SharePoint, other pages and web parts to your application pages. Web Parts should be created to enhance the users SharePoint experience. Create web parts that summarise information from your line of business applications. The idea here is to allow users to create dashboards to quickly get the big picture of what is going on and where they should focus their attention to. Web Parts should not be created for data capture, rather create an application page. Site Pages should be created should you not find a suitable standard SharePoint layout for your dashboard page with all the needed zones. In this situation create your own site page.


About sharepointsriram

9+ Yrs of IT experience
This entry was posted in Sharepoint 2010 Pages & Navigation, Sharepoint 2010 Web Parts. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s