[rules-users] Better Performance and Maintainability?

[Greg Barton]

POJO is the way to go on all three counts:

1 - Data members in a class will be more efficient than a Map.  A Map requires one MapEntry instance for each entry.  Also, primitive data types would require boxing into the java object equivalents.  Both introduce unnecessary inefficiency.

2 - A Map based approach is certainly more flexible.

3 - Both are equally reusable, but since POJO is compiled I generally find it easier to debug. 

There's no reason why you have to go completely in one direction or another.   If there are data members that are known to not change, put them in a POJO.  A POJO can have a map in it for additional, future fields.

--- On Sun, 1/24/10, HonorGod <jagadeesh.motamarri at barclayscapital.com> wrote:

> From: HonorGod <jagadeesh.motamarri at barclayscapital.com>
> Subject: [rules-users] Better Performance and Maintainability?
> To: rules-users at lists.jboss.org
> Date: Sunday, January 24, 2010, 10:38 AM
> 
> Hi,
> 
> Can someone plz help me understand performance and
> maintainability in the
> following scenario - ?
> 
> I load tons of rows of data from database and store them in
> an object fact
> model [POJO based] and apply the rules using decision
> tables and finally
> persist data.
> 
> vs
> 
> I load tons of rows of data from database and store them in
> an object fact
> model [HashMap - Key - Value] and apply the rules using
> decision tables and
> finally persist data.
> 
> The difference in the above two scenarios is that one of
> them is pojo based
> and the other is key-value pairs that are used on LHS of
> the decision
> tables. When I use Key-Value approach I had to do lot of
> conversion in terms
> converting the conditions into eval statements and
> validations but where as
> the pojo approach is very straight forward and less
> validations.
> 
> Which approach gives me better performance and
> maintainability?
> 
> I would consider the following before I make a decision - 
> 
> 1 - size of data
> 2 - frequency at which the data changes [in terms of adding
> new conditions /
> adding new columns / removal of new columns etc]
> 3 - re-usability
> 
> Thank You!
> 
> -- 
> View this message in context: http://n3.nabble.com/Better-Performance-and-Maintainability-tp136941p136941.html
> Sent from the Drools - User mailing list archive at
> Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>