Post by x***@y.comYes, I was talking about System.Data.DataTable.
So you wrote your own class as a substitute for Syatem.Data.DataTable?
No. We never replaced the bulky DataTable. That would not be
significantly better.
If we need to retrieve a table 'Humans' from DB with the columns
int ID,
varchar Name,
int Age,
int Gender, -- 0 unkown, 1 male, 2 female
datetime LastUpdate,
varchar LastUpdateUser,
...
for example then the corresponding POCO (Plain Old Clr Object) looks like
enum Gender
{ Unknown,
Male,
Female
}
class Human
{ public int ID;
public string Name;
public int Age;
public Gender Gender;
public DateTime LastUpdate;
public int LastUpdateUserID;
}
and the table type for this row type is just
List<Human>
If you want to use the old ASP.NET DataBinder.Eval, then you need to add
{ get; set; }
to each line to crate auto properties since DataBinder cannot deal with
fields.
This takes significantly less resources than a DataTable.
The latter uses object[] for the row type, even if you used typed DataSets.
So every value type in the row is auto boxed (int, enum, DateTime in
this case). Autoboxing increases the size by factor 5 or more.
DataTables furthermore have a significant internal overhead for
maintaining state and metadata.
OK, this has been optimized to some degree by using strongly typed
internal column stores for common value types now. But still there is
the autoboxing overhead at each access. In fact the optimization
replaced memory consumption by GC pressure. And there are hundreds of
code lines to be executed for every single field access.
Post by x***@y.comWhat about other objects in System.Data namesapace?
They belong together. You cannot use them independently. AFAIK
everything need to be in a DataSet. Even if you create a single table a
DataSet with all related objects is created internally.
Post by x***@y.comWe use DataView/DataViewRow a lot.
Do we need to wriet substitute classes for those too to work with the
POCO datatable?
Sounds like a lot of re-inventing the wheel.
More like reinventing a square wheel. :-)
DataTables are just fine for 'PowerPoint' requirements, i.E. show a
quick an dirty solution, where everything else does not count.
But in practice I remember only very few cases where they really met the
needs. I do not write applications all the day that open a 1:1 editor to
exactly one SQL table which allows you to edit one data row at a time
and save the result back to the SQL server like Management Studio does.
Most of the time the database point of view and the users point of view
are quite different. Users do not think in normalized relational data
models. They think in business objects with data that belong together
and do not care about cardinality that SQL cannot represent in a single
table.
E.g. the simple concept like 'Friends' does not fit into one DataTable
class Human
{ public int ID;
public string Name;
...
IList<Human> Friends;
...
}
You would need a second DataTable with foreign keys at this point. No
big deal so far. But now you need to write the GUI yourself since users
want to edit all together and not to edit friends in a separate dialog
and deal with bare IDs. If you need to write the GUI and the data
bidirectional binding yourself and therefore also need to track
insertions, and deletions in the friends table yourself, then the
DataTables do no longer simplify that task.
In case of foreign keys in general no user wants to edit them by value
(e.g. ID). So again you need to provide your own editor with change
tracking.
And if we are talking about backend data processing: LINQ will not care
whether you have fields, properties or DataColumns. So the POCOs will
fit your needs just as the DataRows do. But POCOs are faster by about 2
orders of magnitude.
The SQL style filtering and grouping of the DataTables is outperformed
by LINQ too. LINQ also removes the risk of SQL injection, although the
very limited features of DataTables also restrict the potential danger.
Of course, I do not refactor every old (migrated) .NET 1 application
which uses DataTables just because I can do so. But for new designs and
major changes DataTables are no longer an option since .NET 3.5.
(Note I only develop web applications and no Win Executables which are
more difficult to test and to maintain. Maybe WinForms interact smarter
with DataTables and there is more benefit in this case.)
Marcel