ASP.NET Design Suggestions

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

I'm trying to get a good understanding of this.

I have a page that is fairly complex and makes a number of database
accesses. I'd love to cache it but, since the data will be specific to the
user's current settings, that doesn't really seem to be a useful option.

I also have a button that should change some data and then refresh the page.

The problems are:

1) The entire page rebuilds in the load event before the button handler is
called. I know I can test IsPostBack, but when the data changes, I really
need to rebuild the entire page.

2) Since the page has already been build when the button handler is called,
changing the data has no effect.

It almost seems like it would be better if the button handler was called
first. At any rate, I'm just wondering if some of you have dealt much with
this quirk and how best to deal with it.

Thanks.
 
It almost seems like it would be better if the button handler was called
first. At any rate, I'm just wondering if some of you have dealt much with
this quirk and how best to deal with it.
Click to expand...

Page_Load(...)
{
if (!IsPostBack)
{
BindData();
}
}

ButtonClick(...)
{
BindData();
}

void BindData()
{
// fetch the data...
}
 
I have a page that is fairly complex and makes a number of database
accesses. I'd love to cache it but, since the data will be specific to the
user's current settings, that doesn't really seem to be a useful option.
Click to expand...

It depends. And actualy it's posible. What I've done is use asp.net
profiling data and buld "Data Bus" which interacted with that data.

You can find some of my thoughs about this there
http://laflour.spaces.live.com/blog/cns!7575E2FFC19135B4!662.entry?&_c02_owner=1

--
WBR, Michael Nemtsev [.NET/C# MVP].
Blog: http://spaces.live.com/laflour



:
 
I wanted to add something to Mark's post.

First, there is rarely a time when you use IsPostBack. !IsPostBack is
common, as you are first painting the page, but IsPostBack only leads you to
problems. You end up with something like this:

if(!IsPostBack)
{
//Code to paint page initially
}
else
{
if (button1.Click)
{}
else if (button2.Click)
{}
else
{}
}

You then find you are in spaghetti land.

Second, you have evens for each button. Use them.

Third, it is a good practice to separate function, in properly named
routines, from event handlers and methods. Not only does it make intent
clear, but it has an extra bonus if you ever have to obfuscate: None of your
code is easily accessible to those attempting to reverse engineer.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
 
I wanted to add something to Mark's post.

First, there is rarely a time when you use IsPostBack. !IsPostBack is
common, as you are first painting the page, but IsPostBack only leads you
to problems. You end up with something like this:

if(!IsPostBack)
{
//Code to paint page initially
}
else
{
if (button1.Click)
{}
else if (button2.Click)
{}
else
{}
}

You then find you are in spaghetti land.
Click to expand...

I completely disagree with the above... The "else" clause that you suggest
just doesn't happen. There's no way in the world that anyone would do what
you suggest. If Button2 has caused the postback, then its Click (or
whatever) event will fire - there's absolutely no need at all to go through
any of the above logic to check whether Button1, or any other control, has
caused the postback...
 
Indeed. I find the insinuation that "spaghetti code" is "bad" to be
religiously offensive.
 
Back
Top