ibatis-user-cs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: Auditing capabilities on top of IBatis
Date Mon, 14 Aug 2006 16:04:24 GMT
Don't inherit from SqlMapper!!!!   It has an interface ISqlMapper that you
can implement with a proxy class of your own.

In general, be very careful extending classes from any framework.  Look for
an interface first.  If one doesn't exist, your still better off favouring
delegation over inheritance by creating your own facade class.


On 8/14/06, Rogelio Baucells <rbaucells@investran.com> wrote:
> Hi,
> We have the requirement of implementing auditing at the property level
> for our object model. We need to audit all changes to public properties
> and persist the auditing information at the time the entity is been
> saved. We are evaluating IBatis for such task as the persistence layer
> and we have a prototype already working. We had to modify some parts of
> IBatis to acomplish this task:
> 1- We need to modify the way objects are created, for that we created
> our own IObjectFactory and returned our own IFactory for the entities we
> need to audit. This IFactory creates a dynamic proxy with some extra
> functionality needed for the auditing.
> We had to modify DomSqlMapBuilder since there is no way to set a custom
> IObjectFactory at the time of creating a SqlMapper. I think that it
> would be a good enhancement to IBatis having the posibility to specify
> your own IObjectFactory and set/get accessors.
> 2- Another thing we needed was the ability to intercept calls to some
> methods in the SqlMap class, the easiest way to accomplish this was
> inheriting from the SqlMapper class but the contructor is internal. Also
> there is no way to change the way the SqlMapper instance is created
> inside DomSqlMapBuilder and in several places in the code classes are
> using a reference to the SqlMapper class instead of the ISqlMapper
> interface. We finish doing a hack inside our dynamic proxy
> implementation of the domain model entities since the change in the
> IBatis code was a little more complicated than the one before.
> I think the ability to extend/modify IBatis functionality is something
> necessary in some cases and it should be built into the main code base.
> A functionality similar to the Hibernate interceptors is a good idea or
> the possibility to change the default implementation of
> accessors/factories and the SqlMapper itself are needed in some cases. I
> can work on adding those changes to the main code base if the community
> think it is necessary.
> Thanks,
> CONFIDENTIALITY: This email (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited. If you received this email in error, please
> notify the sender and delete this email from your system. Thank you.

View raw message