> The GetContexts(ConfigurationScope) method of the > DomDaoManagerBuilder > class in the IBatisNet.DataAccess.Configuration namespace of the > DataAccess library (whew) doesn't contain any code to parse the > 'implementation' attribute.
In this file: http://tinyurl.com/9r9c7 http://svn.apache.org/repos/asf/incubator/ibatis/trunk/cs/mapper/IBatisNet.DataAccess.Test/bin/Debug/dao_MSSQL_SqlClient.config There are two place where the "implementation" attribute is used: <daoSessionHandlers> <handler id="NHibernate" implementation="IBatisNet.DataAccess.Extensions.DaoSessionHandlers.NHibernateDaoSessionHandler, IBatisNet.DataAccess.Extensions"> </handler> </daoSessionHandlers> and <daoFactory> <dao interface="IBatisNet.Test.Dao.Interfaces.IUserDao, IBatisNet.Test" implementation="IBatisNet.Test.Dao.Implementations.NHibernate.UserDao, IBatisNet.Test"/> </daoFactory> The first "implementation" attribute (in the <daoSessionHandlers> node) is deserialized using the IBatisNet.DataAccess.Configuration.DaoSessionHandler class. The GetIDaoSessionHandler() member of that class uses the following code to return the implementation specified in the config file: type = Resources.TypeForName(_implementation); return (IDaoSessionHandler)Activator.CreateInstance(type, EmptyObjects); The second implementation attribute (in the <daoFactory> node) is deserialized using the IBatisNet.DataAccess.Configuration.Dao class. The Initialize(DaoManager) member of that class contains the following code that deals with the implementation specified in the config file: _daoImplementation = Resources.TypeForName(this.Implementation); > I was just wondering what the reason for this was? Is it on the TODO > list, is it still under review, or is it merely an oversight? I'm > asking in the context (er) that I want to be able to plug in my own > implementation of the IDaoSessionHandler interface... I see that the > extensions library already has such a custom implementation in place > (NHibernateDaoSessionHandler and NHibernateDaoSession), but from what > I can gather from poring over the source, there ain't no way to plug > these extensions in. Perhaps (more probably) I'm just missing another > (easier, equivalent) way? I hacked the source to enable me to plug my > own extensions in, but, well, this is less than ideal. The link to the dao_MSSQL_SqlClient.config file at the top of my post gives an example of how to use your own implementation of IDaoSessionHandler. Is that what you're looking for? > On a related note (yeah, I like to get my moneys worth on these > emails), just how does one plug in an alternate IDalSession into a > SqlMapper instance? The OpenConnection() method of the class in > question actually creates the IDalSession implementation explicitly > ('...new SqlMapSession()'). How do I say (pretty much) 'hold on, > don't > do that, here's one I made earlier... <plugs in custom IDalSession > implementation/>'. According to this file: http://tinyurl.com/7npx9 http://svn.apache.org/repos/asf/incubator/ibatis/trunk/cs/mapper/IBatisNet.DataAccess.Test/Dao/Implementations/DataMapper/AccountDao.cs and specifically these lines: sqlMapDaoSession = (SqlMapDaoSession)this.GetContext(); SqlMapper sqlMap = sqlMapDaoSession.SqlMap; it looks like you get an instance of a SqlMapper from the object that implements IDalSession (SqlMapDaoSession extends DaoSession which implements IDalSession) and not the other way around. Another way to explain it using the more familiar IDbCommand and IDbConnection interfaces is to say you can't create a IDbCommand object and set its Connection property: // wrong, IBatisNet doesn't work like this... IDbConnection conn = GetConnection(); IDbCommand cmd = GetCommand(); cmd.Connection = conn; You must instead do this: IDbConnection conn = GetConnection(); IDbCommand cmd = conn.CreateCommand(); Both of those achieve the same thing (i.e. a IDbCommand object is created with its Connection property set). Make sense? Take my information with a grain of salt until Gilles chimes in with his wisdom. He is the Creator :) - Ron
