Whether you are in the process of building a new business web application or planning to build one, you most likely need to address how your web application will handle displaying different content for different users.

Considerations

When considering the different options for displaying dynamic content you generally need to take into account the following aspects:

Usability

Usability might be one of the most critical aspects in the success (or lack thereof) of your application.

Development Time

This includes the total amount of development time involved in satisfying your current application requirements.

Flexibility

Regardless of how comprehensive your current requirements are, applications tend to evolve over time. It’s important to evaluate the development effort and skill sets required to accommodate changes.

Support, Maintenance & Ongoing Enhancements

Commonly ignored by many when planning new development projects, it is generally responsible for a good chunk of the total cost of an application over the span of its life. This includes bug fixes, client customizations, minor application enhancements and of course, QA and testing.

The Options in ASP.Net

Generally web applications that use ASP.Net have two main options for displaying dynamic content:

Server Controls

With Binding – retrieving the relevant data and binding it to the appropriate ASP.Net server controls on a web form

In Code – populating the appropriate ASP.Net server controls in code

HTML

In Code – constructing the HTML to display in code  based on the information retrieved from the database

Using XSLT – retrieving the database information in XML format and then transforming it into HTML with XSLT

A third option is Silverlight, a relatively young technology introduced as an option for web applications by Microsoft about a year ago.  Silverlight provides a very rich GUI with the power of the .Net platform (a subset, actually) and tools that make web application development quite similar to the latest Windows application development (WDF). 

Comparing the Different Options

Before you decide on the best route to take to display dynamic content you need to evaluate the impact of each approach on your application. You might find the table below helpful when making this decision.

Approach	Pros & Cons	Best Suited For
Server Controls
With Binding	The quickest approach in terms of development time but also the least flexible.	Best suited for applications with low data complexity and that are not expected to change often.
In Code	Hooking up the controls in code takes longer in terms of development but is much more flexible than binding.  This approach also requires a higher level of support and maintenance.	Best suited for applications with high data complexity and that are not expected to change often.
HTML
In Code	Constructing HTML in code gives a good deal of flexibility over the markup that’s created but is time-consuming and extraordinarily brittle.  This approach requires extensive testing and support.	I wouldn’t recommend this to be used as a general strategy for web applications but at times this might be used for particular sections depending on a unique set of requirements.
Using XSLT	Offers high flexibility and the least amount of ongoing maintenance and testing.  The development time might be longer depending on your team’s skill set.	Best suited for applications with high data complexity and ones that are expected to change significantly and frequently. In addition, this allows for a lot of room for creativity as far as interface design goes.
Silverlight	Provides the richest GUI possibilities and the complete separation of interface and code.  The time to develop, test and support are currently higher than other options.	Best suited for applications that require very rich user interfaces, and for development teams that primarily focus on Windows development.

 

Real-World Use Case: Scopings

When we started evaluating the requirements for Scopings, our homegrown recruiting platform, we needed a way to present complex content with a unique look and feel, a high level of usability, an infrastructure that can easily adapt to frequent and substantial changes, and built-in capabilities for globalization.

Very quickly we realized that although we can use ASP.Net server controls to build the first revision of Scopings in a relatively short period of time, this wouldn’t adapt well to the frequent changes we expected to be an inevitable part of the product lifecycle, and it would therefore, substantially increase our total cost of ownership.

After much analysis and many discussions, it became clear to us that designing our own infrastructure for constructing HTML using XML and XSLT would satisfy all of our requirements.  We sat down and started to design an infrastructure that has ultimately been used for more than 80% of the functionality on Scopings.

Constructing Dynamic Content

The idea behind the Scopings infrastructure was to allow us to make substantial changes to our user interface, while eliminating the need for any code changes and development staff involvement, and substantially decreasing the amount of QA required following any changes to the user interface.

To accommodate these requirements the Scopings infrastructure was built to be completely indifferent to the information retrieved from our database and to the way the information is ultimately displayed.

To achieve this we designed the infrastructure as follows:

- A separate stored procedure was built against each web content page to be displayed, and was designed to only output XML.

- Upon loading a web page, we used XSLT to transform the XML received from the database into HTML and display it for the currently logged-in user.

- All HTML styling was handled with CSS.

Given the above approach, any change to the way we display data, or to the content of the page would only involve the following minor modifications:

- If any additional data is needed we would modify the stored procedure to include the new data required. If no additional data is needed, no change to the stored procedure will be made.

- Modify the XSLT to include any new data to be displayed, and any changes to the display.

- Modify the corresponding CSS files to make any changes required for styling.

- Test display changes and specific page functionality if any.

This allows for content and interface changes that require little to no development efforts and can be done very quickly with minimal testing.