Right now... there are two ways of handling an XML file in an easily and with object orientation:
- the intrusive (but more dynamic) TypedDataSet, generated bye the xsd.exe
- And object serialization generated by XSDObjectGenerator.
Each one has its advantages and disadvantages... but I wonder... why we can not combine the advantage of the by changing the internal design of ADO.NET... How?
Well the DataSet... is a collection of DataTables... the DataTable is a Collection of DataRows....
why it is not built to be more flexible? i.e. :
- The DataSet could be an implementation of IDataSet
- The default implementation for IDataSet " the DataSet" could be a collection of IDataTables
- The default implementation for IDataTable "the DataTable" could be a collection of IDataRows
- The default implementation of IDataRow... could be "the DataRow"
This way... I wouldn't have to worry about having to inherit from the DataSet, DataTable or DataRow classes... if that is not what I want... and this way I could create my own independant object hierarchy and... if I want to handle it as a DataSet well, all I have to do is implement the appropriate interfaces...
Of course... making Microsoft change the ADO.NET API to add this flexibility... could be too much to ask (after all there are a lot of applications built on top of the "legacy" ADO.NET) but... what about Mono? they could create an extensible non intrusive interface based dataset... don't you think?