findByAnd(Map) ws findList(EntityCondition)

[Scott Gray-2]

On 11/12/2010, at 4:20 AM, Marc Morin wrote:

> In the spirit of changing the entity/delegator interface more object friendly, why not take this to then next step and generate POJO interfaces for each entity.  These would extend GenericValue but provide a simple gettor/settor facade allowing compile time type checking and removing of the "string" code for much of the business logic written in java.
>
[snip]
>
> This allows code that is much easier to debug and less error prone.. example below is for navigating orders.
[snip]
>  The binding between the entity model and the java implementation can be caught as a compile time error...  significantly lowers the maintenance cost of the code.

In my experience this is simply untrue and something that seems like it might be the case but actually isn't.  The number of bug fixes going into the trunk for incorrectly named entities/fields is minuscule and I would be surprised if it were any more than a couple per year, hardly a source of significant maintenance costs.

Regards
Scott

[Marc Morin]

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.
> >

[Adam Heath-2]

On 12/10/2010 06:37 PM, Marc Morin wrote:
> 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()).

A class based on GenericValue(even one generated dynamically at
runtime, into a custom classloader), is still a class.  Said class is
not loaded on the heap.  It's bytecode is placed into permgen.  More
classes would increase permgen pressure.

[Marc Morin]

Yes, permgen space needs to be increased with this.

Sorry, I mis-understood your objection as a performance related to speed of the newInstance() vs more classes.

Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
[hidden email]

----- Original Message -----

> On 12/10/2010 06:37 PM, Marc Morin wrote:
> > 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()).
>
> A class based on GenericValue(even one generated dynamically at
> runtime, into a custom classloader), is still a class. Said class is
> not loaded on the heap. It's bytecode is placed into permgen. More
> classes would increase permgen pressure.

[BJ Freeman]

this discussion comes up about every 6 months, if you research the
mailing list archive you will get a lot of insight. check both the dev
and user mailing lists. Why not find open source that does what you want
there a few out there, like hibernate? it would seem to be a lot less
effort.

=========================
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

Marc Morin sent the following on 12/10/2010 5:36 PM:

> Yes, permgen space needs to be increased with this.
>
> Sorry, I mis-understood your objection as a performance related to speed of the newInstance() vs more classes.
>
> Marc Morin
> Emforium Group Inc.
> ALL-IN Software
> 519-772-6824 ext 201
> [hidden email]
>
> ----- Original Message -----
>> On 12/10/2010 06:37 PM, Marc Morin wrote:
>>> 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()).
>>
>> A class based on GenericValue(even one generated dynamically at
>> runtime, into a custom classloader), is still a class. Said class is
>> not loaded on the heap. It's bytecode is placed into permgen. More
>> classes would increase permgen pressure.
>