I have thought about this idea, and at first glance it seems cool and
all, but one of the selling points of OFBiz is that it intentionally
stays away from this type of Object->Relational mapping. OFBiz
developers find that direct access to the relational database is easier
to use.
-Adrian
On 12/10/2010 7: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.
We have done such a thing (again in our forked application), and it makes the
Java code much more readable and easier to use. The general structure is
public class Person extends AbstractGenericValue<Person>
{
public static final String ENTITY = "Person";
// constructor, only called from makeValue, MUST be associated with a
delegator
protected Person(Delegator delegator) {...}
// factory method
public static Person newInstance(Delegator delegator) {...}
// generate finders, by pkey, etc...
public static Person findOne(Delegator delegator, String partyId){...}
// getter and settors
public String getFirstName() {
return getString("firstName");
}
public Person setFirstName(String value) {
set("firstName", value);
return this;
}
// relationships
public Party getParty() throws GenericEntityException {...}
public PartyNameView getPartyNameView() throws GenericEntityException{...}
}
This allows code that is much easier to debug and less error prone.. example
below is for navigating orders.
OrderHeader orderHeader = OrderHeader.findOne(delegator, orderId);
// get the orderItems
List<OrderItem> orderItems = orderHeader.getOrderItemList();
BigDecimal totalQuantity = BigDecimal.ZERO;
for (OrderItem orderItem: orderItems) {
totalQuantity = totalQuantity.add(orderItem.getQuantity());
}
I know we want to encourage business logic in minlang, etc... but if it is
written in java, and there is a LOT of code in java, shopping cart, etc...
this makes that code MUST more readable and maintainable. 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.
This may be pushing a rope, but we use this ALL the time for our groovy and java code.
(would also apply to jsp code obviously). Minilang code can be type checked by the
reader... (want to check for static errors in code, without the need to "run"
the code).
We have implemented the generators, and the refactoring/abstracting to enable this. We
find it works great and doesn't break ANY of the nice ofbiz extend entity semantics,
etc.... Of course if you extend an entity and then want java business logic to use it...
you need to access those items either with "strings" as stock ofbiz, or redo an
entity-gen. But if there is no java code using the entities, no need to auto-gen.
As another note, we have done a similar thing with the service interface.... as you might
have guessed, we're a fan of ofbiz extensibility, but NOT on how it encourages poor Java
implementation practices. ("String" object references, non-type safe, public
static methods everywhere.... etc...)
Marc
