Well, technically it is, but that’s not really my point in this.
Working on a project now that has everything coming in as a DataTable to the UI – single entity records, child entity records, lookup data – everything. Using one for a simple ListBox or DropDownList is tolerable, but I still prefer to have my own class that I bind to.
I felt bad for the guy that had to deal with it, writing lines like these to deal with it:
NumberOfUnits = Convert.ToInt32(dt.Rows[0][FIELD_NUMBER_OF_UNITS].ToString());
txtLocation.Text = dt.Rows[0][FIELD_LOCATION].ToString();
Not only is this cumbersome and error prone (nevermind the unneeded ToString() in the first example), it is also not DRY at all. Every time one of these things is needed, the same code was written to extract from the DataTable. Of course, the argument was to “keep it simple” and we know that usually ends up not being simple. Taking the extra small step of creating some entity classes that have a constructor that takes in a DataReader would have not only made the other developers life much easier, it would also allow for further extendibility, encapsulation, etc.