 |
|
^ click above ^ |
07.01.03
 By
Tiberius OsBurn
When I first heard about .NET’s user controls I thought, “What’s this? A proprietary
format for include files?” I argued with a colleague about this newest offering
from Microsoft, dismissing user controls as some sort of hype from Redmond.
Little did I know that not only would I deploy user controls in my daily
design work, I’ve grown to love them.
Include files, for those of you not in the know, were ‘snippets’ of HTML or .ASP
code that were used as header or footer files or anywhere that code repeated.
These include files encapsulated common code, like a copyright warning or a login
area – something that was repeated on many pages in a web application. Most hardcore
developers have used include files before, so you’ll be able to appreciate what
.NET brings to the table with their new user controls.
Simply put, a user control is exactly the same as an include file, except you
get the power of a code-behind and great features that the .NET framework provides
– like caching, events and properties.
Where I’ve found user controls extremely useful is in sidebars, where I have some
sort of content that is small in size and concentrated in functionality. For example,
on my site, tiberi.us, I have a user control for my ‘What’s the Buzz’ column –
I’ve consolidated what would have been an include file in ASP 3.0 into a self-contained
user control, which I can easily design in VS .NET. We’ll take a look at the code
and some design issues later on in this article, but first, let’s take a peek
at what User Controls can offer the .NET developer:
Code Reuse
A programmer gets sick of writing the same code again, or worse yet, doing a search
and replace on every page when some critical information changes. Typically, if
you weren’t using an include file, or if you’re just a glutton for punishment,
you’ve gone through this ugly process.
|
User Controls in .NET really free up your time for real development, rather than
laboriously recoding or doing a search and replace just because some yahoo in
marketing screwed up on the site’s legal footer.
User Control Properties
If you’re trying to ensure you’re not making the same mistakes that you did with
include files, like hard-coding your database connection string – You can look
into providing properties for your user control that you set on the page that’s
slaved the user control. The nice thing about user control properties is that
you can set them at run time – similar to any server or ActiveX control.
You can set the property of a user control in the calling page by passing in the
property name and a value as a parameter when declaring the user control on the
page.
 To
make your pages and your user controls more extensible, you should provide properties
that can be set at run-time – resulting in cleaner code and less distribution
nightmares. Try to avoid hard-coding any property that might change – especially
when coding for the enterprise.
Caching
One of the really great benefits of ASP.NET is the ability to cache a page or
control, which ultimately means less processing overhead for IIS. Instead of dynamically
dishing up content every time an end user requests a page, IIS caches the output
in memory and dumps out that cached content when requested. Caching really comes
in handy when you’re doing something intensive, like a database query. If needed,
entire pages can be cached and dished up to end-users, effectively turning a dynamic
page into a static page. For the purposes of our sidebar, we only need to cache
our small control – this technique is known as fragment caching. Fragment caching
is very slick and allows pieces of your page to be cached for a certain time period
while leaving other pieces to be dynamically created.
Because our sidebar content only changes a few times a week, we could consider
caching it once a day, but that’s not really good design. You might work odd hours
and make an update at midnight and then one at six in the morning, so caching
only once per day won’t cut it. For our purposes, none of the information we’re
caching is critical, so we’ll just go for a once an hour caching strategy. Deciding
when our page or control should be cached is called a caching policy. There are
a few different strategies to consider when you cache your page – we can even
write our caching policy around whether a file changes on our server.
We’ll implement our fragment caching by declaring using the OutputCache directive:
<%@ OutputCache Duration="3600" VaryByParam="none"%>
The Duration attribute sets the amount of time we’d like to cache the control
in seconds, so if you want to cache your user control for 2 minutes, you’d set
the duration to 120. In this case, I’m setting my duration to 3600, which is an
hour for you math geniuses out there. Be sure and consider the right amount of
time to cache your user controls – too little and you could affect performance
and scalability, too much and you’re starving out needed content your end user
is hungry for.
 The
VaryByParam attribute allows you to cache based on GET/POST parameters. It is
a required attribute – here we’ll set it to ‘none’, because we don’t really need
to cache based on different parameters passed in from a querystring. Truthfully,
the VaryByParam is very slick – it allows you to cache any page dynamically created
from a querystring and subsequent requests using the same querystring parameter
will get the cached version.
For example the directive:
<%@ OutputCache Duration="3600" VaryByParam="code"%>
would cache any page requested by a URL passed into a site with the querystring
‘code’.
http://yoursite.com?code=xml
http://yoursite.com?code=csharp
Finally, you can separate all of your GET/POST parameters with a semi-colon –
all of these requests would be cached as well until the duration expires.
<%@ OutputCache Duration="3600" VaryByParam="code;download"%>
We’ve only touched upon the most common uses of fragment caching – I suggest that
if you’re going to use caching, you should really read up on the capabilities
of this most powerful new tool in the developer’s arsenal.
 Building
a better Sidebar
The sidebar on tiberi.us is a very simple yet flexible control that relies on
XSLT Processing, an XML file that contains the content, and an XSL file that tells
the sidebar how the most of the content should ‘look’ to the end user. I felt
that this strategy provided a little bit more control as I tweaked the look and
feel of my site – if I needed to add or take away sections, I could do so by changing
the XML and/or the XSL file – no need to add fields to a database or hardcode
the “look and feel” of the side bar in HTML. This actually was very handy as I
was putting together my site. I originally had the sidebar on the left side of
my page, and was dissatisfied with its position – so I just dragged it from the
left side to the right side, tweaked my layout in the XSL file, and my site was
instantly updated. If I make the decision to change what the layout of my sidebar
looks like today, I’ll just change the XSL file and instantly my site will reflect
those changes.
Hard content vs. Soft content
In my side bar, I’ve cheated a bit and provided some information that I know won’t
change in the actual user control, rather than placing it within the XML file.
Not everything needs to be so dynamic – I do have some information that won’t
change, like my contact information for my web site. This is pretty typical, most
sites have content that WON’T change no matter what – just be sure to use your
head and place what is typically soft content in your XML file and go ahead and
place the hard content that won’t change wherever it is needed.
XML vs. Databases
So, why would you use XML rather than SQL Server? For one thing, Cost. Last time
I checked, SQL Server costs a bundle. Even if you DO have access to SQL Server,
you should look at how scalable your sidebar would be with intensive queries.
All in all, it comes down to performance. Database access is usually the bottleneck
when it comes to performance in most web applications. I’m not saying don’t use
databases, on the contrary, I’m saying use them wisely and only where XML couldn’t
do a better job. I’d offload as much of my ‘static’ content to XML and let SQL
Server do the heavy lifting when needed – like performing a search or serving
up dynamic content.
Click
Here to Read the Full Article
About the Author:
Tiberius OsBurn is a freelance technology author and speaker based in Omaha, Nebraska.
His book, "Hardcore Development", will be released in the summer of 2003. Mr.
OsBurn has extensive experience in VB, VB.NET, C#, SQL Server, ASP.NET and various
other web technologies. Be sure to visit his site, http://www.tiberi.us,
for his latest articles of interest to .NET developers.
Read this newsletter at: http://www.webproasp.com/2003/0701.html |
|
|
|
