Hello everyone,
I didn't want to talk about it until it was a 'core' piece of our
architecture, but MySpace.com is now running IBatis for a good portion of
its data access abstraction layer.
We like the flexibility. I came in from a 'heavier' ORM background but very
much appreciated the configurability IBatis offers against a changing data
storage medium, because we have a whole range of heavily denormalized
databases.
The performance takes a hit due to the multiple reflection calls made
through the system, but we ate that in the name of a nicely abstracted
back-end tier, and with thoughts towards the possibility of using emitted
classes to someday improve performance. (A natural evolution of this kind
of model in the context of the CLR). If there's any efforts we can make in
that direction, please let me know.
The only performance optimization we've made so far is to ensure that the
call to pre-load stored procedure parameters borrows the already-open
connection of the IDalSession above it. We saw that under super-heavy load
the fact that the sproc parameter populator tried to grab its own connection
within the connection of its parent that a semi-deadlock situation would
result, because the parameter populator does all its work in a heavy lock.
Interested in hearing why this was done, because we definitely got a big
boost on app startup post-optimization.
All-in-all I really like the system. I thought it was pretty cool that the
SqlMapper interface was so nicely abstracted that you could plug in generic
collections from 2.0 without a rewrite:
List<MyObject> l = new List<MyObject>();
Mapper.QueryForList("GetMyObjects",myParam,l);
Wishlist?
*Like I said above, emitted types for populating and instantiating result
objects could very well be revolutionary--I'm not aware of an existing
framework that robustly does this.
*Syntactically, better support in the mapping files for stored procedure
parameters. We like the inline parameter methods you can use with dynamic
SQL, would be nice to have a way to use that with sprocs too.
*Better decoupling of SqlMappers from physical databases / db connections.
Decoupling is implicit in the object model, but it's difficult to use the
SqlMapper as 'just' a repository of maps, rather than as an abstraction in
front of a physical database.
Anyways, this is a truly excellent project and we'd like to help any way we
can. This is the best model I've seen for a well structured but heavily
decoupled object -> db scenario.
Chris Bissell
Managing Architect
MySpace.com
