Not everything has to be OO. Both the Java and .NET implementations of iBATIS support dictionary objects. DataTables have an advantage over IDictionary with DataViews:
http://tinyurl.com/2cvqh http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdatadatacolumnclassexpressiontopic.asp and their ability to be serialized through a web service. IDictionary/DataTables come in handy in reporting situations where you don't want to / can't create objects for dynamic reports that need a small amount of additional sorting/filtering that IDictionary can't provide. I think such a method would also help iBATIS get its foot in the door. I would love to re-implement sometimes questionable helper classes liks this: SqlHelper.ExecuteDataTable("SELECT * FROM Users") with ISqlMapper.QueryForDataTable. Another step in iBATIS' evolution may be a generalized Query method: DataTable dataTable = (DataTable)sqlMapper.Query(dataTableQuery, "SelectAccountById", 5); Product[] products = (Product[])sqlMapper.Query(productArrayQuery, "SelectAccountById", 5); ISqlMapper could be re-implemented this way: public IList QueryForList(string statement, object parameter) { return (IList)Query(queryForList, statement, parameter); } public object QueryForObject(string statement, object parameter) { return Query(queryForObject, statement, parameter); } Looking far into the future, maybe ISqlMapper would extend IDataMapper to extend the mapping concept to more than just SQL: MusicInfo[] musicInfos = dataMapper.Query(musicInfoQuery, "FindMusic"); --- Alexandre Grenier <[EMAIL PROTECTED]> wrote: > Although I understand the situation, I wonder if adding support for > datasets would defeat the purpose of ibatis by breaking down the > model > it is promoting. > > My understanding is that ibatis is a base for building a good > "Persistence Ignorance" domain model. > > In the current case you send in a "query" and retrieve "Plain Old CLR > Objects", so the input is aware of persistence, but the output can be > 100% focused on the model. > > In the case you propose, the output being a datatable maintains the > concept of persistence after the fact and is not desirable in a > model. > > Maybe that's not your case, but I feel in most cases it may lead to > bad > design and in the long run injecting Non-PI features will blur > ibatis' > intention. > > > > One way around this would be to enable the user to provide a > mechanism > to process the data and build something else than an IList. > > > > Alex
