Hi Dave,
I have been coding since the early 80s and I agree with you for the O-R
mapping. I think that this is a great way to go although after working with
GenericEntity and Hibernate, I'm torn with which is best but that wasn't my
concern.
What I was referring to is that there are places that we are passing a slew
of arguments around between methods and services where TOs or Model objects
would appear to be more appropriate. The loose type casting and lack of
compilation validation can lead to buggy code.
For example, I am working on the shipping rate engine for DHL. I need
package details (weight, length, width, height, declared value), as well as
origin and destination addresses and several other sets of data. The
original code stuffed all of this information into a Map. Trying to make
this code reusable was difficult and "knowing" what name value pairs were
necessary was work. One other major benefit of the TO/model object is that
the IDE makes it very simple to know what properties are needed and are type
specific.
It would appear to me that some of the service methods would benefit from
TOs instead of having to map out hierarchical data using a naming convention
(i.e. originPostalCode, destinationPostalCode, origin..., destination....)
Thanks,
John
On 11/14/06, David E Jones <
[hidden email]> wrote:
>
>
> This is not an accident or an arbitrary decision. Things are very
> intentionally done this way. In all tiers of the applications in
> OFBiz we are avoiding O-R mapping because in terms of developer time
> and flexibility these objects are very expensive. A few minutes of
> looking stuff up and getting familiar with the entity model saves you
> and all of us hours of maintaining this sort of highly redundant code.
>
> I'm sure I can say that all day and you won't believe me. If you
> really want to convince yourself, try both approaches for a while.
>
> -David
>
>
> On Nov 14, 2006, at 9:01 AM, John Martin wrote:
>
> > Having been working with the ofBiz code for the past couple of
> > months, I
> > have been wrestling with the coding standard a bit. Much of the code
> > utilizes Map objects stuffing individual name/value pairs passed
> > around. I
> > understand the reasoning for the use of Map objects with the
> > service layer
> > but there are many places in the code that Transfer Objects (TOs)
> > would make
> > the code easier to understand and code around. It is really
> > fustrating to
> > have to dig through the code to find all the fields that need to be
> > populated for a method and to make certain that the varible name
> > has the
> > correct spelling and case is accurate.
> >
> > Is there a reason that TOs appear to be avoided in the code?
> >
> >
> > Thanks,
> >
> > John
>
>
Locked
