The facade doesn't instantiate more objects than current, but the class hierarchy is taller. (ie. when GenericValue.makeValue() currently instantiates a GenericValue(), that factory would then instantiate a class based on the entity name, that derives from GenericValue()).
The "speed" of the extra layer for the getter/setter is not worth mentioning. I disagree that OOTB OFBiz should not use this in any part of the offering. The Entity engine should not be dependent on any Entity instance as it isn't, but OFBiz's applications benefits tremendously! Even framework code such as the ControlServlet that is accessing the Visit entity, it has a code dependency between the Visit entity and the Java code, using a Visit facade over GenericValue with "visitId",etc... doesn't hurt. The code for orders, product, etc.. become much easier to understand, follow and maintain. I don't see any downside on any OFBiz code implemented in Java not using this pattern. Am I pushing a rope on this issue? If so, I will stop debating... Marc ----- Original Message ----- > I am happy as long as not OOTB > I doubt that there will be any effort to optimize, under current > design, if they are done in OO way. as you said the path of least > resistance with the fact that the volunteer group does not have energy > to do that. > > > > > ==================== > > BJ Freeman > Strategic Power Office with Supplier Automation > <http://www.businessesnetwork.com/automation/viewforum.php?f=52> > Specialtymarket.com <http://www.specialtymarket.com/> > Systems Integrator-- Glad to Assist > > Chat Y! messenger: bjfr33man > > > Adam Heath sent the following on 12/10/2010 10:17 AM: > > On 12/10/2010 11:54 AM, BJ Freeman wrote: > >> the "facade" is exactly what ofbiz wants to avoid. > >> the extra overhead of the conversion. > > > > I disagree. > > > > OOTB ofbiz should not use any such facades. But having them > > available for end-users to make use of is a win, IMHO. Makes it > > easier for new > > people to get involved in ofbiz. > > > > This facade pattern will obviously be slower; it contains more > > object instantiations, and more method calls. And, in groovy at > > least, those > > end up using reflection. But if it allows people to write more > > application code, which can later be optimized to be faster, then > > I'm all for it. > >
