User Control Implementation: Could It Be More Efficient?

S

Smithers

I have a non trivial ASP.NET Web application that implements its navigation
system via a user control (menu.ascx) placed on every page.

It is important to note that the user control that hosts the menu is
injected into every page at runtime when the page is requested (i.e., it's
not declared in any ASPX).

The user control contains a menu that is dynamically populated and styled at
runtime (fwiw: it's ComponentArt's Menu for ASP.NET - but that's irrellevant
to this question)

The data for the menu is retrieved from a SQL Server database - and loaded
into the menu at runtime during the Page_Load event procedure of menu.ascx.

I have implemented security such that different DataSets are used to
construct the menu: If the current user is NOT logged in, then they get a
standard menu which is stored in the Application state. But once the user
logs in, then they get a user-specific menu - with its supporting DataSet
stored in their Session.

The application code always attempts to retrieve the menu's DataSet from
either the Application state or the Session - and hittis the db only if not
found in one of those places.

This all works very well - and production runtime performance is acceptable.
But I want to do better.

While I have reduced db hits as much as possible, the property values for
the menu are set on *every* page request (during the page_load event of
menu.ascx). This seems like it is or should be totally unnecessary. I would
like to set the menu properties only once and then never again if possible
(with the only exception being that an unauthenticated user logs in - in
which they would get new menu properties - which should then be in effect
for the duration of their session)

ViewState, AFAIK, is how we maintain control property settings between page
requests. But I'm not sure it will help me here. To EnableViewState on
either the PlaceHolder into which I'm injecting the user control, or on the
user control would not help me in this case because the user control is
injected into each page at runtime (via a PlaceHolder) - or so I think. If
I'm correct, then a newly requested page would not have the opportunity to
have the menu's viewstate because only previously-opened pages would have
the menu's ViewState information (and not the currently/newly-opened page).
You can see that this is where I'm getting a little fuzzy on what's going on
here with ViewState as it relates to my application and its menu and hosting
user control.

So - I would appreciate it if someone could shed some light on what's going
on here with respect to ViewState and how I might be able to continue with
my existing architecture (of injecting into each page the menu's user
control at runtime) AND NOT have to continue setting all of the menu's
properties on every page request - and ideally only once or twice per
session).

Thanks!
 
J

Juan T. Llibre

Have you looked into using the Cache object ?
The situation you describe sounds tailor-made for it.
 
S

Smithers

With all due respect - have you actually read my OP?

The whole issue centers around reducing the number of times I set properties
in a user control that is injected into each page at runtime - NOT reducing
db hits. I'm already caching data - just not in the Cache object because it
is not the best place, IMHO, for user-specific values.

If I missed something about how the Cache can be helpful to my particular
situaion - then can you please be a bit more specific?

-S
 
G

garethdjames

Have a look at output caching,

This works by caching the result of the render of a page (or control)
then using this,

In win 2003 and IIS 6 this is a kernal level cache and is very quick
 
B

billmiami2

Why is it necessary for you to place the menu control on the page at
runtime? Do you need to dynamically remove the menu from the page
under certain conditions?

Bill E.
Hollywood, FL
 
S

Smithers

<< Why is it necessary for you to place the menu control on the page at
runtime? >>
Because the location of the menu in the aspx and the particular menu to be
implemented can change at runtime depending on a number of runtime
conditions.

-S
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top