ASP.NET Design Suggestions

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.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Re: ASP.NET Design Suggestions

"Jonathan Wood" wrote in message
news:OY1vvc8WIHA.4696@TK2MSFTNGP05.phx.gbl...

> 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.

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

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

void BindData()
{
// fetch the data...
}


--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Re: ASP.NET Design Suggestions

Okay, yeah, I guess that makes sense.

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Mark Rae [MVP]" wrote in message
news:%23sc%23Dl8WIHA.4548@TK2MSFTNGP03.phx.gbl...
> "Jonathan Wood" wrote in message
> news:OY1vvc8WIHA.4696@TK2MSFTNGP05.phx.gbl...
>
>> 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.
>
> Page_Load(...)
> {
> if (!IsPostBack)
> {
> BindData();
> }
> }
>
> ButtonClick(...)
> {
> BindData();
> }
>
> void BindData()
> {
> // fetch the data...
> }
>
>
> --
> Mark Rae
> ASP.NET MVP
> http://www.markrae.net

RE: ASP.NET Design Suggestions

> 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.

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



"Jonathan Wood" wrote:

Re: ASP.NET Design Suggestions

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!
|
*************************************************
"Jonathan Wood" wrote in message
news:OY1vvc8WIHA.4696@TK2MSFTNGP05.phx.gbl...
> 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.
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>

Re: ASP.NET Design Suggestions

"Cowboy (Gregory A. Beamer)" wrote in
message news:%23RX7IdDXIHA.1208@TK2MSFTNGP03.phx.gbl...

>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.

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...


--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Re: ASP.NET Design Suggestions

Thanks for chasing away the Pastafarians.
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com


"Mark Rae [MVP]" wrote:

> "Cowboy (Gregory A. Beamer)" wrote in
> message news:%23RX7IdDXIHA.1208@TK2MSFTNGP03.phx.gbl...
>
> >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.
>
> 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...
>
>
> --
> Mark Rae
> ASP.NET MVP
> http://www.markrae.net
>
>

Re: ASP.NET Design Suggestions

Indeed. I find the insinuation that "spaghetti code" is "bad" to be
religiously offensive.


"Peter Bromberg [C# MVP]" wrote in message
news:E4E74991-092F-480F-A8C4-796AF3FCCA61@microsoft.com...
> Thanks for chasing away the Pastafarians.
> --
> Site: http://www.eggheadcafe.com
> UnBlog: http://petesbloggerama.blogspot.com
> MetaFinder: http://www.blogmetafinder.com
>
>
> "Mark Rae [MVP]" wrote:
>
>> "Cowboy (Gregory A. Beamer)" wrote in
>> message news:%23RX7IdDXIHA.1208@TK2MSFTNGP03.phx.gbl...
>>
>> >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.
>>
>> 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...
>>
>>
>> --
>> Mark Rae
>> ASP.NET MVP
>> http://www.markrae.net
>>
>>

Re: ASP.NET Design Suggestions

"Peter Bromberg [C# MVP]" wrote in message
news:E4E74991-092F-480F-A8C4-796AF3FCCA61@microsoft.com...

> Thanks for chasing away the Pastafarians.

It all becomes clear once you get pasta certain point...


--
Mark Rae
ASP.NET MVP
http://www.markrae.net