[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_12414975 ]
Jeff Butler commented on IBATIS-50: ----------------------------------- Thanks for the feedback. Good question about lazy loading. But there is no impact because lazy loading just delays the execution of the statement, doesn't change how the statement is executed or processed. I decided to add the idea of optionally creating the objects because I didn't want to force the factory to behave in different ways for managed and unmanaged objects. For example, I would never use an IoC containter to manage a HashMap. So if I wanted to return a HashMap for some statement I'd need to do "new HashMap()", but for other objects I'd ask the IoC container. It seemed cleaner to me to only ask the IoC container for my managed beans and let iBATIS do the work for non-managed beans. But this is optional in my solution - you can do it either way. I think I will pass the statement ID - doesn't waste many cycles and it may be useful to someone. > Ability to override the default bean creation mechanism > ------------------------------------------------------- > > Key: IBATIS-50 > URL: http://issues.apache.org/jira/browse/IBATIS-50 > Project: iBatis for Java > Type: Wish > Components: SQL Maps > Versions: 2.0.9 > Reporter: Philippe Laflamme > Assignee: Jeff Butler > > Currently, iBatis is responsible for creating instances of classes used in > result maps. It relies on the assumption that objects can be obtained using > the Class.newInstance() method (or something equivalent). > The assumption forces users of the framework to create classes with a no-arg > default constructor. IMHO, this also has the effect of favoring > implementation inheritance (extends) over interface inheritance. > Although this is not a problem in most cases, the ability to plug in an > external instance factory would provide more flexibility and favor good > programming practices. Amongst other things, it would provide developers the > ability write code in terms of interface. > A simple solution is to provide an extension point where resultMap class > instances are obtained from. > The simplest form would be: > public interface InstanceFactory { > Object createInstance(Class resultMapClass); > } > The default implementation would do something along the lines of: > [...] > return resultMapClass.newInstance(); > [...] > Developers could configure iBatis to either use the default implementation or > their own custom implementation. The setting could be part of the > sqlMapConfig file or even per resultMap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
