I understand the issue, but would you seriously want to use the second syntax over the first?  There's gotta be a better way to test this than resorting to Container.DataItem syntax.

JP Boodhoo had a nice way of creating a mapper that could be easily tested.

So you make your code uglier because you don't want to inconvenience a tool that you intentionally make yourself dependent on? I <em>really</em> don't understand everyone's fascination with tools like Resharper. Write less code, write simpler code, and you won't think you need more tools.

@Jeffrey I thoroughly disagree that I "see no value in strong typing"! Wow, there is so much wrong with that statement that its hard for me to begin.

First, I love strong typing. Love it. I can't ever conceive of me voluntarily using a language that isn't strongly typed for any considerable amount of code. Strong typing is so much better than weak typing. I really don't want to live in a world where everything is a scalar or a var. I think you have confused strong typing with static typing. I assume you know the difference and hope that wasn't intentional.

Second, I see very little value in static type checking at compile time for the vast majority of the code we write. Sometimes you need it, but mostly you don't. Alot of the arguments I hear against dynamic typing smell like FUD. It seems to me alot of the approaches taken in the C#-heavy Alt.NET world are to get us around the problems static type checking and code bloat. Static type checking leads to code bloat, which makes folks think they need Resharper. But, if you control your code bloat, you don't need Resharper. A really good way to control code bloat is to use a strongly typed, dynamic language like Ruby or Python.

@Jeffrey I think this all comes down to the fact that I believe that you shouldn't use unit tests to determine the correctness of your presentation tier. There are other better ways to test your presentation tier, and relying on the static type checking at compilation is a bad smell to me. (I know thats the second time I've said "smell" in my comments. I don't mean to imply that anything you said in this post was FUDdy.)

Also, I disagree that dynamic vs. static is orthoginal to code bloat. Both Steve Yegge and Jeff Atwood blogged recently about this recently.

steve-yegge.blogspot.com/.../codes-worst-enemy.html

www.codinghorror.com/.../001025.html

Strongly typed databinding can be done using Lambda expression in .Net 3.5

This little helper function solves the issue.

private static string MemberName<T>(Expression<Func<T>> exp)

       {

            MemberExpression me = exp.Body as MemberExpression;

           if (me == null) return "";

           return me.Member.Name;

       }

Using the

<%# Eval(MemberName(() => customer.EmailAddress)) %>

You only have to get  reference to the Customer instance...

I would like to hear your opinions :-)

Regards Morten

A point which seems to be missed by this whole post is that the second syntax actually performs in a much faster way.  Using the Eval method on an object (not a dataset) results in the use of Reflection.  By casting the DataItem to the appropriate type and then acting on the public property we no longer rely only reflection to obtain the needed value, resulting in improved performance.

However, I actually prefer a third syntax.  I prefer to place controls in the ASPX file while I then assign values to in the code-behind on item databound.  This way I still get all of the benefits of your second syntax, but none of my perceived cluter.  I feel that this keeps the ASPX file cleaner and easier to read.

One thing that Eval does is ignore nulls, so you can do something like

Eval("Status.Name")

And it will return an empty string rather than throw.

I see nothing wrong with Eval("EmailAddress"). Its much easier for end users to find my errors rather than the compiler. ;-)

Why are people doing their databinding in the asp.net page. AHHHHHHHHHHHHHH!!!!!!!

Get it out of there and start using your code behind but keep the scripting and binding out of your asp.net page.

YEEHAA