Jeffrey Palermo 1:47 pm on January 2, 2008

Improve maintainability of ASP.NET databinding

Most of us (I think) don’t have full browser automated testing through Watir or Selenium. Because of that, even though we have tons of automated NUnit tests, we could still have problem in web pages in ASP.NET because these aren’t fully tested with the build.

Even with Resharper, refactoring often leaves bad property references in databinding code that looks like this:

<%# Eval(“EmailAddress”) %>

If we get rid of the EmailAddress property on the object we’re binding (or rename it), this would break.

If we convert the above line of code to the following, we benefit from strong typing (and Resharper helps us out a little more). We can precompile the web application to ensure all references in web pages still work. After all, compilation is a low-level form of testing. It would alert us of a bug.

<%# ((Customer)Container.DataItem).EmailAddress %>

Chris Sutton 2:30 pm on January 2, 2008

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.
Sean Feldman 3:17 pm on January 2, 2008

JP Boodhoo had a nice way of creating a mapper that could be easily tested.
Mike Moore 5:05 pm on January 2, 2008

So you make your code uglier because you don’t want to inconvenience a tool that you intentionally make yourself dependent on? I really 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 Palermo 5:48 pm on January 2, 2008

@Mike,

This tip is orthogonal to Resharper and is focused on making databinding code more maintainable. Regardless of the refactoring tool, changes in objects require changes to databinding code, and these problems pop themselves up if they can be detected with a compiler.

This is really about increasing the speed of the feedback loop. With an Eval(“string”) how long can the problem hide before it’s found.

I understand your predisposition to dynamic languages, and you see no value in strong typing. I can respect that viewpoint, and I know it’s working very well for you.

Yes, the code is a bit uglier, but I’m open for other options that would speed up the feedback loop if one of these property bindings became incorrect.
Mike Moore 9:28 pm on January 2, 2008

@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 Palermo 10:19 pm on January 2, 2008

@Mike,
Forgive me. I did mean “static” typing, not strong typing in general.

For code that’s easily unit-tested, static type checking isn’t so valuable because the automated unit tests are what count. In the case of my post, ASP.NET markup is near impossible to unit test, so in this case, I find it valuable to leverage the ASP.NET pre-compiler to find any type errors.

Regarding dynamic typing arguments: there are none here.

Regarding your last statement about controlling code bloat. I think this, too, is orthogonal to dynamic/static languages. Neither will do anything for you with regards to code bloat. You can write bad/bloated code with either, and you can write small, tight code with either. Writing the correct code in an iterative fashion with a tight feedback loop will help with code bloat because you will only write what’s completely necessary and nothing more.

Thanks for the comments. I’m also subscribed to your blog’s rss feed.
Mike Moore 11:12 pm on January 2, 2008

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

http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
http://www.codinghorror.com/blog/archives/001025.html
Morten Overgaard 8:36 am on January 5, 2008

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

This little helper function solves the issue.

private static string MemberName(Expression<Func> exp)
{
MemberExpression me = exp.Body as MemberExpression;

if (me == null) return “”;

return me.Member.Name;
}

Using the

customer.EmailAddress)) %>

You only have to get reference to the Customer instance…

I would like to hear your opinions 🙂

Regards Morten
John Chapman 2:11 pm on January 5, 2008

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.
Ayende Rahien 3:07 pm on January 6, 2008

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.
Dave 5:28 pm on January 9, 2008

I see nothing wrong with Eval(“EmailAddress”). Its much easier for end users to find my errors rather than the compiler. 😉
Ron Paul 5:23 pm on January 10, 2008

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.
Ron Jeremy 10:50 pm on January 15, 2008

YEEHAA

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Improve maintainability of ASP.NET databinding

Related