Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For data bound controls (Repeater, ListView, GridView, etc.), what's the preferred way of binding data?

I've seen it where people use Eval() directly on the aspx/ascx inside the data bound control to pull the data field, but to me, it just seems so...inelegant. It seems particularly inelegant when the data needs to be manipulated so you wind up with shim methods like <%# FormatMyData(DataBinder.Eval(Container.DataItem, "DataField")) %> inside your control.

Personally, I prefer to put in Literal controls (or other appropriate controls) and attach to the OnItemDataBound event for the control and populate all the data to their appropriate fields in the code-behind.

Are there any advantages of doing one over the other? I prefer the latter, because to me it makes sense to compartmentalize the data binding logic and the presentation layer. But maybe that's just me.

share|improve this question
add comment

3 Answers 3

I suggest you to go through this SO Question : Eval and ItemDataBound or RowDataBound event to display data, which one is better?

Base on the performance comparsion on the title : Real World ASP.NET Best Practices Using inline format expression mechanism (i.e. tag) is better than event hanlder mechanism (via ItemDataBound).

As i explored about this that the DataBinder.Eval syntax uses reflection and should be avoided if you can determine the object type at design time. Ref: Avoiding DataBinder.Eval in ASP.NET

Check this for Asp.net performance and scalibilty :

share|improve this answer
add comment

First off: Eval is pretty bad. As @NiranjanKala's answer mentions it uses Reflection to get the value of the relevant property/field, and using Reflection to get values from object members is very slow (see this article for more details).

As for the other two syntaxes, it really depends. I used to be a proponent of the event binding syntax, as it reduces clutter in the ASPX file, and keeps the databinding logic and the markup separate. Plus, it's easy to debug and you can make use of other features such as sub-repeaters that share templates with the parent repeater for hierarchical data, or the ability to turn other Controls inside the repeater on and off based on accessible data. I think it really fits with the "stateful web" approach that WebForms goes for.

However, more recently I've been doing a lot of MVC and you can really apply a similar approach to the repeaters; bind a pre-formatted object, and you no longer need to worry about your "shim" methods being in the ASPX:

protected class MyUiBoundClass
{
   public string DataField {get;set;}
}

public IEnumerable<MyUiBoundClass> PrepareForBind(IEnumerable<MyEntity> entities)
{
    return entities.Select(x => 
                new MyUiBoundClass {
                    DataField = FormatMyData(entity.DataField)
                });
}

public void LoadAndBindData()
{
    /// Load some data from somewhere.
    IEnumerable<MyEntity> myData = this.SomeService.LoadMyData();
    IEnumerable<MyUiBoundClass> myFormattedData = PrepareToBind(myData);

    this.MyRepeater.DataSource = myFormattedData;
    this.MyRepeater.DataBind();
}

If you use this ViewModel-style pattern you separate the data formatting from the markup, and still get to use the faster and more concise <%# %> syntax. Plus, you've pretty much solved the "harder to debug" issue that normally comes with the <%# %> syntax, as you would find all the debug-worthy code in the PrepareToBind method.

share|improve this answer
    
That is a very old article, dealing with .NET 1.1; reflection got much, much faster in subsequent versions of the framework. Presuming they are doing some reasonable things, like caching some of the lookups, Eval probably isn't as slow as one would think. –  Wyatt Barnett Jan 25 '12 at 22:43
    
True, but I've never found an equivalent article for any newer revisions. I have done numerous benchmarks on the Repeater databind and Eval normally comes up around an order of magnitude slower than the <%# %> syntax. Last time I tried this was using .net 3.5, admittedly, and an order of magnitude is still only a few ms, but that's not the point; the point is that if you have two options that are effectively identical you might as well pick the faster one. –  Ed Woodcock Jan 25 '12 at 22:57
add comment

I think building in codebehind has some significant disadvantages in workflow -- mainly that changing output formatting for a web app requires a recompile.

Personally, when I was doing ASP.NET webforms, I would cast the Container.DataItem to the appropriate object and then bind directly to that object. Also opens the door to smarter formatting and such as you can access members of said object.

Performance-wise, I don't think it is probably a wash in real-world conditions. There typically is enough data transfer on a remote network that any micro optimization one might make in rendering the list will never make a difference.

share|improve this answer
    
It shouldn't matter that it requires a re-build as you should never make manual changes in production. And you'd be surprised at how much slower the Eval method really is, I think, but you're right, performance is normally related to factors other than your choice of databinding syntax. –  Ed Woodcock Jan 25 '12 at 21:23
    
No, you shouldn't. But we have deployed some templates only updates that didn't even bounce the app. And then there were a few "don't try this at home" moments. Moreover, it is really a design time thing -- I'd rather hit save and refresh and see results, rather than save / rebuild / wait for app to spin up / log back in / see results –  Wyatt Barnett Jan 25 '12 at 22:42
    
I agree, sometimes it can be useful to be able to mess with the HTML without a full deploy cycle, but for the standard build/test/debug cycle I'd probably be more bothered about the amount of warmup time after the build than about having to rebuild to see changes. Simple app resets can generally be pretty snappy if you handle your caching right. –  Ed Woodcock Jan 25 '12 at 22:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.