Right now, we're using Spring.NET to load a Chain of Responsiblity implementation that we ported from Jakarta Commons. Many of the Commands in these Chains run iBATIS statements. When we run into one of these commands, we often flip over to the iBATIS configuration to review what the query actually does. In practice, the iBATIS configuration acts like a "code-behind" for our command configuration. I just keep thinking that it might be convenient to have both configuration files in the same format.
-Ted. http://www.husted.com/poe/ On 9/2/05, Rick Evans <[EMAIL PROTECTED]> wrote: > Are you proposing that one configure one's SqlMapper directly though > Spring.NET XML - statements, result maps, etc? Spring.NET (and Spring) > is a great integration technology... why would one want to subvert all > the bells and whistles that one gets with the 'standard' iBatis.NET > configuration files? Ok, 'subvert' is too strong a word here... I'm > all for centralising configuration, but what exactly does one 'buy' by > moving iBatis.NET configuration into Spring.NET? Am I just biting the > wrong end of the stick here? I recently committed code to the > Spring.NET CVS HEAD to facilitate the configuration of iBatis.NET > SqlMappers, DaoManagers, and Daos from within Spring.NET.... nothing > more than simple IFactoryObject implementations, because I felt that > the configuration options offered by iBatis.NET were more than > adequate. > > Enlighten me Ted... if you can convince me that this is a good thing, > or show me how to remove the wrong end of the aforementioned stick > from my mouth, please do :) > > Ciao > Rick
