I've tried this out in my app and the functionality and speed are great. However some of the design choices have me a bit perplexed. I had to do some surgery to get it working with my existing code and workbooks, but I would love to see those changes done properly. I recognize that what I'm suggesting here would be a big change, and may be considered outside the scope of this project, but I think it would open it up to a much broader audience. These are just suggestions. Happy to help out if there is interest. (In fact I'll be doing it anyway because I have to ;-)
- This doesn't actually do what an IDataReader is supposed to do (forward-only cursor). In the implementation, it eager-loads the entire workbook into a DataSet. There isn't any way to efficiently pick and choose what you want. This would be a nice utility to have in addition, but makes it unusable for the real world (e.g,, multi-MB workbooks with tens of worksheets) both for performance and memory use. What I would normally think of as the actual cursor implementation is locked up in the AsDataSet() method. At a minimum that needs to be factored out.
-
If you look at its related interfaces and the other implementations, IDataReader is intended to collaborate with these other interfaces rather than have the whole kitchen sink. Implementing IDbConnection makes it easy to factor out the set up and tear down of the "database" and IDbCommand lets you query just what you need. This is a typical workflow in our app:
using (IDbConnection conn = Factory.CreateDbConnection(...)
using (IDbCommand command = Factory.CreateDbCommand(conn, ....)
{
command.CommandText = "SELECT * FROM SomeSheet";
using (IDbDataReader reader = command.ExecuteReader()
{
// Do stuff
}
command.CommandText = "SELECT * FROM SomeOtherSheet";
using (IDbDataReader reader = command.ExecuteReader()
{
// Do stuff
}
}