On 5/27/05, Bob Hanson <[EMAIL PROTECTED]> wrote:
> To allow for this I have been editing iBatis source so that I can
> difine absolute path locations for my sqlmap.config and sql maps.
> Because I wanted to minimize how much iBatis code I was changing, I've
> relunctantly left providers.config in my client projects but I'd
> obviously prefer that it stay with my DAL.
I think something like providers.config makes an excellent case for
embedding resources. If we could bundle this into an assembly, then we
wouldn't need it floating about, like the odd man out.
Likewise, if your DAL is fully tested, you could deploy the production
version as an assembly using embedded resources. Of course, during
development it is very convenient to leave the configuration as
resource files, since they can be quickly edited and reloaded.
(Especially for interactive unit testing.)
If the sqlmaps.config loads a properties file (e.g,
sqlmaps.config.xml), you should be able to keep from hardcoding paths.
You should be able to define part or all of the path in the properties
files, and then inject it into the config using a ${variable}. Then,
if you don't want those left out for a production deployment, they
could be embedded. (Or not, depending on your priorities.)
> Those two clients only access my BLL and domain objects. They (and
> future client code) should not have any knowledge of the DAL which
> means that all configuration of iBatis should be done by the DAL.
For even more decoupling, you can use something like Spring.NET to
inject the Mapper
dependency. If the reference to the Mapper is exposed as a public
property on your base class, Spring can inject the Mapper instance
for you.
That's what my team is doing now. Next, I'm going to try wrapping the
iBATIS mapper in an interface of our own, so that our API is entirely
decoupled from the iBATIS API. Spring can inject the iBATIS mapper
instance, but our class will only access it through our own (copy-cat)
interface.
Of course, that leaves the door open to injecting a mock version of
the Mapper, if we ever needed such a thing.
-Ted.
