mostlylucid

scott galloway's personal blog...
posts - 911, comments - 723, trackbacks - 11

My Links

News

Archives

Post Categories

Misc. Coding

Small point...what Databinding syntax does everyone use?

UPDATE: OK, before anyone points out the obvious (actually after many people have!) - I am aware that DataBinder.Eval promotes code reuse to some degree; you still have to know what your fields are called of course! My point in this post was that I rarely saw the alternative syntax used and that in my experience I have found almost no drawbacks in using the 'Strong' syntax. This was also a trawl for comments to get the opinions of other developers...with that in mind, let the comments recommence...

Incidentally, in the post below, if anything looks screwy, sorry, having problems with the stupid Rich Text editor again!

Reason I ask is that most of the examples I see all over the web use the:
format...
now the reason for this seems to be that this is  allegedly 'easier' to use and read.
To be honest, I have never used that format, I tend to use this:
<%# string.format("{0:c}",((dbdatarecord)container.dataitem)["price"]%="">  format
now, I understand that this looks more complex  but as it points out here,
"It is important to note that DataBinder.Eval can carry a noticeable performance penalty over the standard data binding syntax because it uses late-bound reflection. Use DataBinder.Eval judiciously, especially when string formatting is not required. ".
Now, in my tests (I benchmark everything...obsessive? Quite possibly :-)), the Eval syntax is a LOT slower, like up to 20% slower - so, what is the actual advantage of using it?
OK, my opinion on why you wouldn't use the 'explicit casting' syntax (i.e., the one I use):

  1. You have to import the correct namespace depending on whether you use a DataSet or a SqlDataReader (or any IDataReader) (System.Data and System.Data.Common respectively).
  2. You have to cast to the 'correct' object so for DataSet it's DataRowView and for SqlDataReader (or any IDataReader) it's DbDataRecord...for any other objects, it's the correct object obviously :-)
  3. It's more 'wordy'
  4. Very few examples show this syntax...

Now, these are pretty good reasons to use the DataBinder.Eval syntax, but to be honest, I just don't find them compelling...so here's some reasons to use the 'explicit casting' one:

  1. You have to import the correct namespace depending on whether you use a DataSet or a SqlDataReader (or any IDataReader) (System.Data and System.Data.Common respectively) - same argument...but I have to say, I like this! It's more explicit about what namespace you're actually using and forces you to know this stuff!
  2. You have to cast to the 'correct' object so for DataSet it's DataRowView and for SqlDataReader (or any IDataReader) it's DbDataRecord...for any other objects, it's the correct object obviously - again, the same as above...knowing what type of object you're using is, in my opinion, a good thing, it gives a whole lot of control in how you represent the object; for example you get access to all the nice DateTime formatters in the .ToString() method - same as you would in code!
  3. It's faster - now this is not a 'be all and end all' argument, but it is important, especially in high-hit sites or when you have to bind really long lists of data - faster = less time for which a thread is used!
  4. Makes you look like a smart ass - OK, just me then :-)

Anyway, I really am interested in hearing people's opinions on this one...which do you prefer, and why?

%>]]>

Print | posted on Tuesday, December 09, 2003 4:25 PM | Filed Under [ ASP.NET ]

Feedback

Gravatar

# re: Small point...what Databinding syntax does everyone use?

Wow!
Finally, one that says and proves that... Cool
As far as I have been able to disassemble, DataBinder.Eval ends up using reflection which poses it in terms of late vs. early binding. The percentage sounds reasonable.
Probably, the only counterindication is that Eval doesn't force you to know the exact type of object you're working with. (In fact, it figures it out at runtime...)
So far, I've found this useful sometimes in control development when you build data-driven controls. I firmly believe the real programmer shouldn't use it in pages.
12/9/2003 5:13 PM | Dino Esposito
Gravatar

# re: Small point...what Databinding syntax does everyone use?

Thanks, I hate when people make assertions like I just have, so I'm trying to dig out the benchmark I wrote previously (or failing that, just write a new one, it's a very simple thing!). Yes, Eval using late-binding through reflection is incredibly useful sometimes - but to be honest I've fond thus far that it's a very small 'sometimes'...ah well, thanks for the comment (even though "Building Web Solutions with ASP.NET and ADO.NET" uses the 'other' syntax it's still a great book :-))
12/9/2003 6:05 PM | Scott Galloway
Gravatar

# re: Small point...what Databinding syntax does everyone use?

20% performance hit vs No dependency of a datastructure (code / presentation) + less coding time.

just call me silly but ill take the 20% hit :)
2/25/2004 2:11 PM | Mischa
Gravatar

# re: Small point...what Databinding syntax does everyone use?

Less coding time - you're talking a few seconds less...which is fairly trivial to be honest. No dependency - well that may be important to you, to me it's not so important - I tend to stay with one DataProvider after the page is built - so actually knowing what my row is can be an advantage (if you do any work on the row in code-behind - you really need to know what the rowtype is!). It's pretty much 'use what you like', performance is one argument, but if you have problems planning what data provider to use / remembering one of three objects to cast to, then DataBinder.Eval is just fine. If performance and explicitness is important - as it is to me - then the explicit casting method is better.
2/25/2004 3:06 PM | Scott Galloway
Gravatar

# re: Small point...what Databinding syntax does everyone use?

I'm a little too late into this discussion but Scott, you're a good example of how Microsoft discourages separating logic from presentation and even discourages code reuse. If you ever went to reuse your code you'd find out that DataBinder's reflection is a lot better concept since you're not going to be forcing everybody using the code to use your data types. Reflection can handle data records, structures, hash tables and more with the same code, direct casting cannot. And 20% performance hit is actually a lot (and I mean a lot) smaller than what I thought reflection would have and is far outweighted by the ability to reuse code.
3/21/2004 10:47 PM | Jerry Pisk
Gravatar

# re: Small point...what Databinding syntax does everyone use?

Hmm...Jerry did you actually read my article - I do point out the exact point you made. In the type of work I do day to day, I don't make controls for external reuse - I actually prefer to know what type of object I'm using and this far outweighs the 'reuse' issue for me. Microsoft hasn't ever encouraged me to do anything like this...in fact the messages coming out of there are pretty much the opposite.
I have no beef with people using DataBinder.Eval. The 'your datatypes' thing...hmm...I've been coding ASP.NET applications (for lots of customers) for a while now - I tend to use DataSets of SqlDataReaders say, 90% of the time with custom collections for all others - my way of working simply has not reduced my level of code reuse...
3/21/2004 10:59 PM | Scott Galloway
Gravatar

# Confessions of a DataSet Flip-Flopper / Custom Entity Waffler

Confessions of a DataSet Flip-Flopper / Custom Entity Waffler
8/2/2004 7:13 PM | Brendan Tompkins
Gravatar

# re: Small point...what Databinding syntax does everyone use?

In my early ASP.NET experience I used DataBinder.Eval, because that was easier and because you see it in all the examples. But now I like to use the explicit way, but for another reason than the ones explained above.
When I'm working with a database, I normally use typed datasets that are generated by Visual Studio based on a schema I specify. In that schema it's possible to say what columns are nillable and what value should be returned in case of null.
DataBinder.Eval does not use those settings, because it uses the normal DataSet, not my typed dataset. So I use a syntax as:
<%# ((MyTypedDataSet.MyDataRow)((DataRowView)Container.DataItem).Row).MyColumn %>
In this way my typed dataset is used, and when a value in MyColumn is null it returns the NullValue I specified in the schema.
12/6/2004 10:22 AM | Wouter
Comments have been closed on this topic.

Powered by: