Re: OOP - a question about database access
From: Costin Cozianu (c_cozianu_at_hotmail.com)
Date: 11/10/03
- Next message: Universe: "Re: OOP - a question about database access"
- Previous message: Universe: "Re: Type regimes - terms and themes (Was: Naive, possibly silly question [LONG] )"
- In reply to: John Urberg: "Re: OOP - a question about database access"
- Next in thread: John Urberg: "Re: OOP - a question about database access"
- Reply: John Urberg: "Re: OOP - a question about database access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 10 Nov 2003 12:40:24 -0800
John Urberg wrote:
> "Costin Cozianu" wrote:
>
>
>>What's wrong with improving the design table by table, and use case by
>>use case, one at a time ?
>
>
> Consider your classic VB+SQL application. SQL is embedded in every form
> and report.
Truth being told, I have never written a real app in VB+SQL. I only
toyed with it, and I refer to it as the most populatr environment.
However I did write quite extyensive applications in Delphi (Borland's
Object Pascal) +SQL which is a most improved version of VB. You may as
well be right and that I heard is a problem in many VB apps, but it was
never a problem in my Delphi apps.
In any case, in Delphi you can group your query objects in modules
(called data module) and you have quite an effective way to manage your
code much better rather than what you suggest.
However, on some forms I did put a Query object right on it, cause
that's "the simplest thing that could possibly work" (TM), isn't it ?
> Every change to a table has ripple effects across the
> application. It's an enormous, error prone job. Why not just rewrite the
> application and isolate the code from the data access so I can not just
> change the data model, but also have the option to change database systems
> too?
>
If a change in a table has ripple effect accross the application , I
would definitely say that the applications is written badly. I've done
schema changes often enough and never had any major problems like you
describe. It is unrealistic, even for a Delphi/VB app that a table
column is refered all over the place, maybe in 2 or 3 forms, which is
pretty much the same as you have it in an object model driven app.
And the same table is updated typicvally from one module only.Does a
change in the object model involve changing all across the apps in the
UI forms that pull data from that object ?
Then often time you can change the schema, you can replace the original
tables with views, but if you come with this "avoid SQL at all cost"
attitude you're much less likely think about them.
>
>>It is just because, as I explained in another post here, the data access
>>pattern generated from O/R mapping are sub-optimal. Wehn compared to say
>>the simplest VB+SQL programmer that has to take the use case from point
>>A to point B, the queries issued from an O/R solutions are generally
>>less efficient. And they will allways be less efficient than I can
>>write, but that's not relevant :)
>
>
> I realise that. But coding in Java provides sub-optimal performance
> compared to using Assembler and I don't think you'd recommend we choose
> Assembler, would you?
>
Now that is the kind of Red Herring you always are expected to hear. But
exccuse me, Assembly is a 2GL, while Java is a 3GL therefore Java is
quite a level of abstraction higher. But Java is 3GL while SQL is 4GL
and is safe to regard SQL as higher abstraction, or in the worst case,
you cannot say that Java is at a higher level of abstraction ?
If you think that you know any better please have a look at:
http://www.c2.com/cgi/wiki?ManyToManyChallenge
Surprisingly, last time I looked not even the Gemstone ODBMS had a good
API to handle that challenege without writing significant code base and
taking care manually of thorny issues (like locking and concurrency and
deadlocks), while in SQL is a snap. It is very certain that you don't
have a ready made class in Java to do that.
> For the price of creating the objects and mappings and a little OQL here
> and there, I no longer have to write any SQL.
Much ado about nothing. Now common, SQL is just 4 lousy statements, why
is it such a scare crow for OO people ? You think OQL is any better ?
What OQL, in what implementation ?
If you look at a classic
> VB+SQL application, that turns out to be quite a significant savings.
I would count the LOC, and I'd bet that a Delphi + SQL + (Objects just
strictly where are needed) has significantly lower LOC.
If
> there turn out to be places in the app that perform poorly, I can still go
> back and optimize those using hand coded SQL.
>
>
Agreed, but you can look the other way:
If there are places where you think you need objects, put them there one
at a time :) You go much faster with SQL and Forms.
In any case, Uncle Bob claimed that you can build your object model as
if no database was behind. Well you could for simple apps.
For complex business apps you are going to hit a barrier, where if you
do not assume from the beginning that the Use Case is going to be
handled by a carefully crafted SQL transaction, the limitation of the
object model becomes a problem, and the code written in
"100% pure objects in memory, that will map them later".
Will simply be terrible (both as LOC and performance. See
http://www.c2.com/cgi/wiki?EjbTernaryRelationshipExample
where the EJB framework falls flat on its face (most O/R frameworks will
do the same) to handle a simple use case.
That's why I shall advocate a balanced approach: we'll see on a use case
by use case, basis, whether we use objects from the object model, or
just throw away the quick and dirty SQL to have it ready in 30 minutes.
One time I used objects to model the metadata about tables, and instead
of writing "dirty SQL" I simply used the metadata objects and methods
that emulate the composition of relational operators to generate the SQL
itself. It works extremely well.
>>Anyways, model driven, MVC and all that jazz are not the same as they
>>were when it was invented in Smalltalk. In typical enterprise apps
>>architecture, an object model is just a partial fragment of the whole
>>model, that is not necessarily unique -- each request processing will
>>have its own copy of some fragment of the model, and has a short life
>>span just for the duration of a transaction. So a lot of the original
>>philosophy behind it doesn't apply.
>
>
> I completely disagree. The Smalltalk folks had to deal with the same
> thing. I doubt they could load the whole database into memory for every
> transaction; they also had to select a specific subset of the object model
> just like I do today.
>
The Smalltalk folks didn't have the query and concurrency problems that
SQL dbmses are designed to handle.
In any case, fundamental to classical object models is the notion of
object identity. This allows for example a controller to be anchored to
that object and send notifications to several views (an example of that
is VisualAge, Eclipse, etc), so they have a simple cache over the object
model. Now this notion pretty much evaporates as several copies of the
same information will be active independently in concurrent
transactions. In any case, I don't think even the controller makes sense
any more (inspite iof everybody creating MVC2, MVP, etc...).
> Regards,
> John Urberg
>
>
best,
Costin
- Next message: Universe: "Re: OOP - a question about database access"
- Previous message: Universe: "Re: Type regimes - terms and themes (Was: Naive, possibly silly question [LONG] )"
- In reply to: John Urberg: "Re: OOP - a question about database access"
- Next in thread: John Urberg: "Re: OOP - a question about database access"
- Reply: John Urberg: "Re: OOP - a question about database access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
