By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,190 Members | 2,204 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,190 IT Pros & Developers. It's quick & easy.

User Control Implementation: Could It Be More Efficient?

P: n/a
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!
Nov 19 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Have you looked into using the Cache object ?
The situation you describe sounds tailor-made for it.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"Smithers" <A@B.com> wrote in message news:eu**************@tk2msftngp13.phx.gbl...
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!

Nov 19 '05 #2

P: n/a
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


"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:ex**************@TK2MSFTNGP14.phx.gbl...
Have you looked into using the Cache object ?
The situation you describe sounds tailor-made for it.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"Smithers" <A@B.com> wrote in message
news:eu**************@tk2msftngp13.phx.gbl...
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!


Nov 19 '05 #3

P: n/a
re:
I'm already caching data - just not in the Cache object
That's why I asked.
Sorry to have disturbed you.


Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"Smithers" <A@B.com> wrote in message news:ua**************@TK2MSFTNGP10.phx.gbl... 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
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:ex**************@TK2MSFTNGP14.phx.gbl...
Have you looked into using the Cache object ?
The situation you describe sounds tailor-made for it.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"Smithers" <A@B.com> wrote in message news:eu**************@tk2msftngp13.phx.gbl...
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!



Nov 19 '05 #4

P: n/a
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

Nov 19 '05 #5

P: n/a
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

Nov 19 '05 #6

P: n/a
Thank you very much! I'll take a look.

-S
<ga**********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
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

Nov 19 '05 #7

P: n/a
<< 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


<bi********@netscape.net> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
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

Nov 19 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.