Re: Persistence, EJBs and OO-Relational mapping
Date: Fri, 15 Dec 2000 19:07:42 +0100
Message-ID: <91dmjp$6kr$06$1_at_news.t-online.com>
<sriniv79_at_my-deja.com> wrote:
> > from the way you are choosing your arguments, I get the feeling that
you are
> > approaching the problem the wrong way around. "Relational arithmetic"
is
> > nothing natural. It was developed from bookkeeping data in
spreadsheets.
> > That is by no means a very effective look at business rules.
>
> I was talking about business data, not business rules. What's better
> than Relational Arithmatic to deal with the "bookkeeping data in the
> spreadsheets" that gets us books from Amazon.com to the right address
> billing the right amount?
Business rules are superior.
- not bound to table logic - better readable - support for inheritance - easier reuse for different purposes - type-safety - ...too lazy to complete the list - the biggest advantage:
less effort for reengineering and automatic help by compiler type-safety
An example for your Amazon problem:
class Article{
void send(Person recipient){
recipient.account().deduce(price());
}
abstract double price();
}
class Book extends Article{
double price(){
return 34.50;
}
}
> > Reality consists of objects.
>
> ??
By definition.
>
> > Even simple data can always be viewed as an object:
> > - data is generated by some method whatsoever
>
> ??
Data is always added to a table.
A principle of OO-programming:
Store methods, that perform an action on an object with the definition of
the object.
You can't do that with the relational approach.
> > - rules can be applied for relationships between data objects
>
> Could you please give some examples?
The above Amazon example ist not very thorough, but it shows the point.
> My original question was about persistent middletier components, such
> as EJBs, and their suitability to persist pure relational data. My
> customers do not work with ODBMS, so can not take much comfort from
> them.
Tough!
I can't help you there, I am afraid.
In my opinion objects and tables do not match.
Some popular support:
http://www.ambysoft.com/mappingObjects.html
> > Viewing data as objects makes life easier for the programmer.
>
> Depends on who the programmer is, and what programming he/she does. In
> my view, nothing is simpler than seeing data in its natural format.
In nature, you always look at singular objects.
> For
> some types of data, such as spreadsheets, tables and records are the
> most natural format.
I don't agree here.
Set algebra (SQL) is very difficult to learn.
What makes OO so nice is that you only view one object at a time. The more you can isolate a problem, the easier it is to understand.
> > Storing object data to relational databases just does not work because
> > paradigms do not match.
>
> Isn't the other way true too?
That is what I said in the first place:
You take the relational paradigma as given and ergo objects are the wrong
way.
It might be right for your sight.
> > The OO-paradigm is by far more natural and easier to handle than
> > relational set-arithmetic.
>
> I do a lot of programming in both paradigms. I totally disagree with
> that assertion.
From your mails, I doubt that you have thoroughly understood the benefits of
OO business-logic.
Tools, APIs and databases have not reached the quality standard of aged SQL
databases, of course.
SQL set logic seems to be more convenient because the technology is here.
Future object APIs will be superior.
Cheers,
Carl
Received on Fri Dec 15 2000 - 19:07:42 CET