Chris McKenzie's Blog

I use OnItemDataBound when I have to and not when I don't. I certainly run into both cases frequently. If, in the future, new needs require more advanced formatting/processing, it's typically trivial to move all/parts to the OnItemDataBound event.

"Always implement things when you actually need them, never when you just foresee that you need them" sums up my view of this one...

I'm afraid I'm with your co-worker.

I generally use server tags in the HTML, particularly if I've got some weird and wonderful formatting going on in my table. I find it easier to picture what's going on with all the layout and content bunched together.

Although I also use <%# GetMyWeirdlyFormattedString(Container.DataItem("Name")) %>

if it's very weird.

Oh well. Guess we're all different

We build DataGrid columns in code-behind.
1)Declaration of DataGridColumn on page level makes easy to reference it on every DataGrid event(by Column index)
2)We can change the way Grid looks and behaves by changing code in one place(Lets say we have corporative Date format and you want to change it)
3)In future we will be able to hold Grid columns information in configuration file/database

I too am with your co-worker. Doing it The Declarative Way makes it, IMO, easier to maintain (a designer can add/remove things if he/she like without having to worry about breaking dependent code). Doing everything on ItemDataBound also means that you somehow have to find the right controls (assuming you don't build the whole control hierarchy for each item there). This _may_ be problematic in certain situations when dealing with container controls (read: controls implementing INamingContainer).

Sometimes you have to do more than simply output data in the data object. In that case I would add helper methods in the code behind and call that, like Benjimawoo suggested. That way I think you generally have the best of both worlds.

Or you could stay away from the DataGrid altogether. We have used repeaters extensively across our applications. We wrote a custom paging control as well as built in sorting. The render time on a repeater is much shorter than a datagrid and you can control the html without having to override the lifecycle methods of the control.

I figure someone will say something about tediousness of writing html with the repeater, but we code generate most everything for list pages, and even if we have to customize something at least 60% or more of the work has already been done.

I believe that any DataLayer must be a simple code block, that they allow operations against DB.

That code block would not have to know on the Business Entities. Single to specialize it is to execute the operations (Store Procedures and SQL Sentences) against the engine DB (SQL, Oracle, DB2, etc.), with which this setting.

Finally, I invite to you to download the DataLayer.Primitives Public Version.

This is very cool Data Layer :)

DataLayer.Primitives - Readme!
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1389

Cheers,

Javier Luna
http://guydotnetxmlwebservices.blogspot.com/

I rarely use DataGrids - I just find that they're too restrictive and I have too much overhead. I'm a big fan of simply using repeaters to code up lists that look/feel exactly the way I want. Everytime I start with a DataGrid I end up replacing it as the functionality of the list grows. That being said, I prefer the declarative method. When I'm already using an <asp:... > control I try to keep as much of the presentation with the control rather than pushing it into the code behind. It usually ends up cleaner and easier to read.

My 2 cents:

I go with the repeater/code behind approach for the simple reason that a code change will break at compile time.

This:
<%# Container.DataItem("AttorneyName")%>
will not break until you visit the page if you've changed the object that is populating the control.

This:
private void repeater_ItemDataBound(object sender, RepeaterItemEventArgs e)
{
if (e.Item.ItemType == ListItemType.AlternatingItem || e.Item.ItemType == ListItemType.Item)
{
// Get the object for this row.
AnObject o = e.Item.DataItem as AnObject;
if (o!= null)
{
// Set the fields.
Label name = e.Item.FindControl("labelName") as Label;
if (name != null)
{
name.Text = o.Name;
}
}
}

Will break at compile time if AnObject has changed.
Of course, this means you have strongly typed objects instead of SQL queries but the only place a SQL query should exist is in the DAL.

There is a ViewState symptom to consider in the realm of programmatic versus declarative server control initiation debate; at least within the 2.0 framework.  

If you rely on a server control’s view state to retain its data across postbacks, so that you’re not required to continuously re-load the control every time the page refreshes, asp will store your entire data set for that control in view state (that’s about 136 lines x 1024 characters worth of view state for a single DropDownList control populated with approximately 5000 records).  All changes made to server controls via the code-behind file are lumped in with asp’s interpreted "user-initiated control changes" and so are preserved within view state rather than stored server-side.

Alternatively, declaratively binding a server control to a DataSource object, such as a SQLDataSource or an ObjectDataSource, will store the control’s associated dataset server-side eliminating the size-able view state that will travel to/from server and users' browsers for each page request.            

Similarly, any property setting changes made to controls in a programmatic manner, such as the control's styles, maxLength, databindings, etc will ALSO be recorded and maintained within the page's view state.

Is this really an issue when you're talking about rich server controls such as the GridView which already occupy more than a substantial amount of ViewState?  That all depends on your unique situation, but it's food for thought.    

Pingback from  ~Hikaru {Aka}Yuuki~  &raquo; Blog Archive   &raquo; Declarative vs Programmatic binding with ASP. NET

Pingback from  Well&#8230;I do DEE-CLAY-AIRE&#8230; &laquo; Bloggerriffic!!