[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58255 ] Philippe Laflamme commented on IBATIS-50: -----------------------------------------
I'd like to comment on the points you made Clinton... 1) I understand your point that state objects shouldn't have different behaviours. But it is reasonable that a state can be extended to add behaviour in certain contexts. Take unit testing for example: from a common interface, you could create an extended version of a state object with some sort of "validation" behaviour so it can validate itself. Also, proxies could be used to inject all sorts of security, profiling, logging, etc. functionalities, that do not alter the bean's behaviour. 2) My statement in regards to the needs of a no-arg constructor was not a complaint. I was simply stating that the requirement could limit the ability to integrate iBatis into non-standard "legacy" applications. Also, the JavaBeans specification provides the Beans.instantiate() method which is designed (amongst other things) to isolate calling classes from the bean instantiation mechanism. This, I think, is the whole issue here: isolation. 3) I agree. Where can I read about the <subclass> element? We might not agree on the intended uses mentioned (I'm not saying they're good ideas anyway), but would you agree that isolating iBatis from the bean instantiation mechanism is important? Personally I think it would provide greater flexibility to your framework without pushing the burden onto users. > 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 > > 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
