Results 1 to 4 of 4

Thread: How to use spring beans as iBatis type handlers

  1. #1
    Join Date
    Sep 2010
    Posts
    7

    Question How to use spring beans as iBatis type handlers

    as you know Ibatis allows to create type handlers as this one:

    <resultMap id="myIBatisResult" class="myClass">
    ...
    <result property="pojoProperty" column="idColumn"
    typeHandler="foo.bar.MyTypeHandler"/>
    ...

    </resultMap>

    THere is no more problem if you just need to make a translation between a number and an enum or something like that, but if you need some other class to collaborate with foo.bar.MyTypeHandler, maybe it would be better to inject a spring bean instead of just a reference to a class allowing this way to inject some other beans to use inside the type handler class.

    Is there a supported way to do this when Ibatis is integrated with spring or do I have to resort to complex and not safely statically accesible ApplicationContextAware or things like that?

  2. #2
    Join Date
    Feb 2009
    Posts
    4

    Default

    Is there a supported way to do this when Ibatis is integrated with spring
    iBatis is not integrated with Spring, instead Spring encapsulate iBatis but still, iBatis don't know shit about Spring. Thus what you are asking for (injecting some other beans to use inside the type handler class) is certainly not possible AFAIK.

    On the other hand, iBatis type handlers where designed for rudimentary or straightforward type conversion (usually to or from a string representation) and thus having the need for another (business) bean from a type handlers sounds like a warning to my hears.

    If you really have complex operation involving other beans in your iBatis type handlers, then you'd probably better move that code into your DAO - which should itself be a spring managed bean, and thus Spring DI enabled - as a before/after sql insert/retrieval processing.

    Hope that make sense,
    ZartC.

  3. #3
    Join Date
    Sep 2010
    Posts
    7

    Default

    Thank you for your very informative answer.

    You are right, type handlers shouldn't be used for complex things (i.e. when a bean is required) but consider a scenario where the dao should return a list of beans, and these beans are persisted in a table, but half of the data is in an xml, and maybe some other data required to fully populate the pojo is gathered through a web service. Of course it could be done in DAO classes but don't you think it is a cleaner approach to allow IBatis to manage all of this by its own?

    By the way, now I understand that spring is encapsulting IBatis, and providing helper classes for it (as the template), but it maybe could be possible to modify the way spring loads Ibatis sqlMapConfig to allow spring inject beans for typeHandlers, maybe with a spring namespace in SqlMapConfig configuration...
    What do you think?

  4. #4
    Join Date
    Feb 2009
    Posts
    4

    Default

    Quote Originally Posted by hablutzel1 View Post
    You are right, type handlers shouldn't be used for complex things (i.e. when a bean is required) but consider a scenario where the dao should return a list of beans, and these beans are persisted in a table, but half of the data is in an xml, and maybe some other data required to fully populate the pojo is gathered through a web service. Of course it could be done in DAO classes but don't you think it is a cleaner approach to allow IBatis to manage all of this by its own?
    If I understand you well, your are assembling objects in a list, where part of each object data come from the database while other parts are coming from XML source and/or WebService. In this case you'd better move that code even higher in you layer stack. In extenso, I would develop what is called a TransferObjectAssembler. A TransferObjectAssembler would firstly call your DAO to retrieve the list of -partial- objects from the database, then it would walk the list of partial objects and call XAO/WebServices to retrieve the remaining data from external sources and complete the partial object. Once all objects are complete, the TransferObjectAssembler can return the list.

    Conceptually, a TransferObjectAssembler sits in between your Service layer classes and the DAO, XAO, Werservices layer. Your services know that when they need that data, with is complex to assemble, they must get it through the TransferObjectAssembler instead of calling a DAO directly.

    Quote Originally Posted by hablutzel1 View Post
    By the way, now I understand that spring is encapsulting IBatis, and providing helper classes for it (as the template), but it maybe could be possible to modify the way spring loads Ibatis sqlMapConfig to allow spring inject beans for typeHandlers, maybe with a spring namespace in SqlMapConfig configuration...
    What do you think?
    If you adopt the design architecture discussed above, I think it is not necessary

    Hope this make sense.
    ZartC.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •