Check this out:
public DataSet SelectDataSet(string statementName,
object parameters)
{
DataSet ds = new DataSet();
IMappedStatement statement =
Mapper.GetMappedStatement(statementName);
RequestScope scope =
statement.Statement.Sql.GetRequestScope(parameters,
Mapper.OpenConnection());
statement.PreparedCommand.Create
(scope, Mapper.LocalSession,
statement.Statement, parameters);
Mapper.LocalSession.CreateDataAdapter(scope.IDbCommand).Fill(ds);
return ds;
}
> -----Original Message-----
> From: Ron Grabowski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 6:30 PM
> To: [email protected]
> Subject: RE: Creating a DataTable from an IList returned from
> the data mapper
>
> 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
>
