This isn't Object->Relational mapping but Relational->Object mapping. It
doesn't change ANY of the obiz entity semantics, it just provides a facade over
the entities that can optionally be used by Java code (not framework code, but
application layer) to recognize that the business logic IS tightly bound to
entity (by name), fields (by name) and relationships between entities (by
name). THis facade just moves these already existing bindings from "strings"
to Java native mechanisms, so that you get compile time errors, if you rename
an entity, field, type, relation, etc...
BUT most importantly, you don't get a bunch of GenericValue's and
List<GenericValue> in the java application code. They become meaningful
business entities that allows code easier to follow and thus less bugs and
easier to maintain.
Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
mmo...@emforium.com
----- Original Message -----
> 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
