As a long time user of iBATIS.NET, I pretty much agree with everything that Rob has said here--though as a user of Castle NVelocity, I would recommend not touching that particular project with a 64-foot pole; I would be concerned with iBATIS.NET acquiring that dependency if it hasn't already. It's a great templating language, but the implementation is not healthy. I also imagine that it would limit iBATIS.NET's evolution options in the future, such as precluding the ability to pre-generate code files instead of inspecting an XML configuration at start up.
As iBATIS.NET evolves, it would be nice if it continued to "grow into" the .NET idioms as Rob has enumerated here--things like enrolling in System.Transaction, using the built-in <connectionStrings> in the app.config configuration, heck, even using the standard configuration classes at all. This would at least help to eliminate the necessity of providers.config, which has always seemed a bit odd to me. My only real hangup is that it'd be nice if these major feature changes occurred in a branch that obviously contains breaking changes--e.g., "3.0"--and not munging them together with existing maintenance 2.x branch. (The Castle project, MonoRail especially, has been in "Release Candidate" mode for seemingly its entire life, and the only way to get important bug fixes is to track the trunk and upgrade along with all of its new features, which is insane.) My two cents. My thanks to the community for all the hard work! V/R, Nicholas Piasecki Software Developer Skiviez, Inc. n...@skiviez.com 804-550-9406
