Fear and Loathing

# re: DataTable vs. BindingList<T>

I'd go for bindinglist<T>. The thing is that with a datatable, the dataview which is bound to the control also has to do the same things as bindinglist<T> has to do: both implement ITypedlist and provide property info for the objects in the list/dataview (done once).

A dataview also iterates through items to find rows, though it could create indexes, however I don't think that will matter that much.

About bloatware: code of a class is shared among all instances of the class. This means that if you instantiate a lot of objects of the same class, you won't lose extra memory if the class is big: all objects share the same code / IL in memory

# re: DataTable vs. BindingList<T>

Go with BindingList<T>.  Its pros outweight the DataTable pros.  The other concern with DataTables is the possiblity of Microsoft implementing another data access framework (DAO,RDS,ADO,ADO.NET, etc.).  You can't go wrong with using business objects.  It is more work but you will have a better solution in the long run.

Also, Brian Noyes has a great book on .Net 2.0 Databinding.  It has examples on how to wire your business objects up to easily maintain their data changes.

# re: DataTable vs. BindingList<T>

Why anyone would consider using a DataTable is beyond me.

# re: DataTable vs. BindingList<T>

I'm a fan of BindingList<T> as well.  The one thing you lose with BindingList though is the sorting and filtering that are available over DataTables through the DataView.  You can filter and sort the DataView without affecting the underlying table.  Very nice.

Unfortunately, there is no such "out of the box" view for arbitrary domain objects in a BindingList<T>.  To solve this, I wrote ObjectListView, which provides a sorted, filtered view over any List<T> (all without altering the underlying list).  Check it out at my blog: www.teamjohnston.net/cs/blogs/jesse.

Cheers,

Jesse Johnston

# re: DataTable vs. BindingList<T>

There is nothing inherently wrong with DataTables. Just use them when the pros outweigh the cons. Not every application is going to get Amazon's traffic. If I'm writing a one-off utility for my own personal use to read in an Excel spreadsheet, for example, I'll read it directly into a DataSet with an OleDbAdapter and bind to the table without bothering to convert to objects.

In short, I use DataTables for quick and dirty but I don't get attached to them. They're the first thing in the list of refactorings if the app starts growing even a little.

# re: DataTable vs. BindingList<T>

I'm a fan of BindingList<T>.  What you do lose with BindingList, though, is the sorting and filtering capabilities of the DataView.  You can bind a control to a DataView, and sort and filter without changing the underlying DataTable.  This is a big deal for real-world scenarios.  Unfortunately, there is no "out of the box" view for BindingList<T> or any collection of arbitrary domain objects.  Typically you'd sort (re-order) or filter (remove items from) the list directly, and reconstitute it from the original datasource as needed.  Not pretty.

My solution to this was to develop my own ObjectListView, a sorted, filtered view for any IList of arbitrary objects.  Sorting and filtering in ObjectListView does not alter the underlying list, and there can be multiple views over the same list.

The code is free, and you can download it from my blog at http://www.teamjohnston.net/cs/blogs/jesse.  There are several postings there that describe the implementation as well.

Cheers,

Jesse

# re: DataTable vs. BindingList<T>

Travis:

try to bind a collection of strings to a grid and add a new one :)

# re: DataTable vs. BindingList<T>

Hi,

Using a strongly typed DataTable would negate the con regarding human errors. However its inabillity to map DBNull to Nullable<T> is a strike out for me.

I recently looked at the innards of the Select mechanism and concluded that performance-wise & maintainabillity you're much better off using either Linq (the compile time checking) or just rolling your own index / iterator...

Cheers

# re: DataTable vs. BindingList<T>

p.s.

I meant using Linq or your own index/iterator on the BindingList<T>.

On a side note; I do like the change tracking of the datatable, allthough the implementation chosen is hardly sufficient for my needs.

# re: DataTable vs. BindingList<T>

The biggest annoyance with BindingList<T> is that it doesn't natively support sorting. I can't believe MS left that out. It's not too horribly difficult to subclass and add, but it's annoying that we have to.

# re: DataTable vs. BindingList<T>

Have a look at the BindingListView class (http://sourceforge.net/projects/blw). It provides a "view" approach for binding .NET objects. Maybe this could be of value?