Best practice - should DataBinder.Eval be used in a 3-tier architecture?

[Mike Lerch]

Pretty much, TSIA, but I'll expand a bit: I'm still trying to get my
head around the n-tier approach to web design. It seems to me that
when you use DataBinder.Eval in the ASPX that your tiers aren't fully
separated. If you're displaying data in a DataGrid, is it appropriate
to define a label in your template column as

<asp:Label runat="server" Text='<%#
DataBinder.Eval (Container.Data Item, "MyField")% >' />

or is it better to do that in the code-behind as part of a databind
event? Or am I missing the point because really the .aspx.cs
code-behind is really still part of the presentation layer? It just
seems counter-intuitive: I'd like to be able to say to someone, "you
go design the front-end and make it all pretty, and I'll work on the
data and business tiers." But it seems like we can't do that (at
least at the .aspx level if not the code-behind) unless they have
knowledge of specific field names and stuff when we're using
DataBinder.Eval .

If anyone can provide me with some pros and cons of the
DataBinder.Eval in .aspx approach, I'd appreciate it!

Lerch

[Darren Clark]

I use DataBinder.Eval as i use a lot of repeaters as our designers dont want
fixed table layouts like you get with a datagrid.

As far as worrying about a ntier solution... Just because you use
databinder.eval doesnt mean you can design it with a property nteir
solution.

As we use typed and untyped custom objects that inherit from datasets to
store our data. And we use this to bind to the repeater or whatever the
object is.

however as long asy ou arent bind a datareader to the repeater then you can
still design ina nteir way.

As far as wanting peopel to design the front end of a site... then mayeb the
approach you are using is not right.

what i have found works really well is the followg.

1) Build the site in PURE HTML First... iron out all UI issues and design
issues before even touching code... helll even make sure the file names are
..htm

while that is being done... or after you have done it..

Build you backend code... you biz objects and data access , core etc.

then put it alltogether...

that way once you get to putting the site togehter you dont have designer
trying to play around with all the aspx pages as their job is already done.
anyway just my 2 cents worth.... sorry about any mistakes or typos.. just
ina hurry this morning
"Mike Lerch" <ml************ ****@bigfoot.co m> wrote in message
news:pi******** *************** *********@4ax.c om...

Pretty much, TSIA, but I'll expand a bit: I'm still trying to get my
head around the n-tier approach to web design. It seems to me that
when you use DataBinder.Eval in the ASPX that your tiers aren't fully
separated. If you're displaying data in a DataGrid, is it appropriate
to define a label in your template column as

<asp:Label runat="server" Text='<%#
DataBinder.Eval (Container.Data Item, "MyField")% >' />

or is it better to do that in the code-behind as part of a databind
event? Or am I missing the point because really the .aspx.cs
code-behind is really still part of the presentation layer? It just
seems counter-intuitive: I'd like to be able to say to someone, "you
go design the front-end and make it all pretty, and I'll work on the
data and business tiers." But it seems like we can't do that (at
least at the .aspx level if not the code-behind) unless they have
knowledge of specific field names and stuff when we're using
DataBinder.Eval .

If anyone can provide me with some pros and cons of the
DataBinder.Eval in .aspx approach, I'd appreciate it!

Lerch