[ http://issues.apache.org/jira/browse/IBATIS-50?page=comments#action_58256 ] Clinton Begin commented on IBATIS-50: -------------------------------------
>> 1) Take unit testing for example Unit testing frameworks such as JMock and EasyMock allow you to dynamically extend your domain model without mangling the domain design. >> Beans.instantiate() method which is designed (amongst other things) to >> isolate calling classes And the ultimate result of Beans.instantiate()? Answer: result = cl.newInstance(); Beans.instantiate() is intended to allow beans to be transparently desirialized or instantiated, depending on the security privileges, environment and configuration (and whether a serialized version of the class exists). It doesn't give the developer any additional control over the object creation process, and still requires a parameterless constructor. Furthermore, this is a contradictory argument, because if you're going to deserialize your bean from the disk, why would you be trying to retrieve it from the datbase? Where's the data? I can't think of even a single interesting (or even safe) use of such a design (please share if you have a real world example). >> 3) I agree. Where can I read about the <subclass> element? The platform independent (.NET/Java) developer's guide. http://prdownloads.sourceforge.net/ibatisnet/DevGuide.pdf?download >> would you agree that isolating iBatis from the bean instantiation mechanism >> is important? Not me personally, and especially not for JavaBeans. Perhaps for non-bean POJOs, this might be useful. The good news is that it's logged here in JIRA, and people can vote for it if they like. I'm sure you're not alone, and this feature could be implemented in a future release. We don't really ever say "no" to anything (unless it's seriously contradictory to the goals of the framework --which this is not)...we just prioritize. Cheers, Clinton > 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
