Re: OOP - a question about database access

From: John Urberg (john_urberg_at_no-spam-yahoo.com)
Date: 11/12/03 

Date: Wed, 12 Nov 2003 13:16:13 -0600

"Costin Cozianu" wrote:

Opps...hit the send button to fast...

>> You miss the point. What takes less code: writing a bunch of 4GL SQL
or
>> using a tool that generates it and hand coding little or no SQL?
>
> Oh, but you have to write the code for objects, for moving the data
> between objects and the controller, plus the mapping files, plus the HQL
> or whatever.

I write the code for the objects and mapping file once. That's the key
difference. From there I can ask the mapper to load an object and it
magically materializes it and it's related objects (whether 1-m or m-m)
from the database. There's lots of SQL alone I've saved writing, not
counting all the insert/update/delete statements it handles.

Not only that, but now I get to work with domain objects. What is closer
to the conceptual model of the system, a subgraph of domain objects or a
bunch of result sets returned from multiple SQL SELECTS?

> And the mapping files, I always thought of them as a true delight. Now
> why shoould I really bother to learn yet one more DDL, which is written
> in XML style (pretty verbose) so that now I have a long chain of
> different languages abstraction:
>
> Database SQL+DDL -- Mapping Files -- Java Files
> |- HQL

So you believe abstraction is bad? It's bad for me to be able to just ask
for an object and automatically get my graph of objects; instead I should
worry about all the selects and which joins I need to make to load all the
data I need for my screen?

>>
http://www.hibernate.org/hib_docs/reference/html_single/#collections-s1-11
a
>
> I don't have enough time to study Hybernate, but it looks to me almost
> as bad as the EJB solution. It's still unclear how you query over it
> (solve the real query posted at the above URL), not just the modeling
> part.
>
> So I think that Hybernate will fall flat on its face also.

Give it a try before you make assumptions. If I have time, I'll work up a
solution and post it to c2.com. Can't guarantee anything though.

>> Most Smalltalk folks writing business applications used an RDBMS.
>
> Well, precisely. They should be using Gemstone/S, shouldn't they ?

They would still have to deal with issues of concurrency whether they are
using Gemstone or an O/R mapper over Oracle.

> Now, if each controller is tied to exactly 1 concurrent transaction, as
> it is in most web application typically the controller has pretty much
> nothing to do (is redundant).
>
> The role of controller in old Smalltalk or Delphi applications was to
> support multiple views, and in case changes were made from some parts of
> the code to the underlying model to make sure that the views are
> notified to refresh themselves. For example if I act and trigger a
> refactoring of the code through a refactoring tool in Eclipse, all the
> windows that display a view of the affected code get updated
> immediately. That's one essential part of the controller in MVC.

Actually, I think your understanding of contoller is wrong here. See
http://ootips.org/mvc-pattern.html for more details.

Anyway, imagine I have a number of screens that display customer name
open. I select a customer to edit and change the name. Those changes
can't be seen in the other screen until I hit OK and the changes are
applied to the data store. So the customer edit screen has to have a
different customer object than the other screens do.

Regards,
John