[Fwd: Re: Question about BasePgActionC.java]

re-post

-------- Original Message --------
Subject: Re: [MVC-Programmers] Question about BasePgActionC.java
Date: Sun, 16 Mar 2003 08:01:49 -0500
From: Vic Cekvenich <[email protected]>
Organization: baseBeans Engineering
Newsgroups: MVC-Programmers
References: <[email protected]>

i will give my comments....

Hue Holleran wrote:
> Hi Geeta,
> 
> 
>>>I have been studying the BasePgActionC class and have a basic
> 
> question.   What BasePgActionC seems to be doing is gathering all the
> "main code" in the various action classes together and cleverly using
> reflection in the dispatchEvents method to call  the appropriate method:
> say, onSaveExc, or onZoomExec, etc.  I'd like to know what the
> advantages of this approach are. <<
> 
> The difference, as I see it - the baseBeans approach reduces the amount of
> code it is necessary to write to achieve CRUD. It is perfectly conceivable
> to reduce this even further by, for instance having xxxDAO to be parameter-
> (or more likely metadata-) driven, i.e. for 'standard' tables one need only
> have the table name and primary key field and we could create the 'DAO
> helper' object to be used. I co-authored an article back in December 1997
> (for "Database Advisor") with Andy Kramek on exactly these topics of
> providing object access to data with an OO language. From my experience this
> type of approach can be very successful - hence my significant interest in
> the work Vic is doing.
> 
> As an aside, we implemented a very similar approach back in early 1997 using
> Oracle and we were able to get insert speeds on a _2-tier_ client/server
> application of around 600-1,000 records per second - this was using a very
> similar technique to what Vic is discussing here. Ok, we were using a custom
> compression technique between the client and server and custom Oracle
> 'packages' on the server that could re-assemble this information - there was
> a lot of framework code. But the real benefit was that there was minimal
> code to setup for CRUD, even multiple master/detail was a breeze and
> performance was staggering.

minimal code and fast, you got it.

> 
> The real disadvantage I see is that the success of this technique can be
> highly dependent on the database structure and, ideally, your 'front-end'
> entities need to closely match the tables in the database 

kind of... we started with html and a navigational view, iteration 1&2.
Then we said 'code to contract', the formBean MUST match the the view,
else it's not Struts.
The DAO implementation MUST populate the formbean somehow, no mater how
hard or easy it is, that is the contract and that is the requiremt. So
we do analyasis and design to achive this.
Here are some scenarios:

#1. We did outputs, the value of reqs. up front, by doing the report
design. If we did, then we know how this sytem will be used ....
therefore we created a data model matches the way it will be used
(outputed) thus there is close corespondance.


#2. Mostly people select display. For exapme display status of order or
a list of loans, etc. Becuase we are sql bound (in Ibatis.com or RowSet)
we can write a nice and fast sql query with showplan or a stored
procedure, that will go against the data in the most efficent way.
Also, we have a zero copy aproach (no VO or DTO) and are using JDBC raw,
so nothing faster. (plus it's disconected/cached). So fast and simple.


#3. What if you need to update a complex form, like insurance or a tax
form? That would be next presentation / lab (my final) on compunding
unit tested beans. Hint: The benas much match forms, so if a form is a
invoice and invoice items.... then the beans are....
Oh you just have to wait.

- otherwise you
> end-up doing a lot of complex joins in SQL to get the result set you need
> for DAO. 

Bad design = bad joins = slow.
If we do a good requirments (yeah, we forget to) then we have a simple
design and simple joins and fast.

But sometimes (most of the time) the data model is fixed, and we still
explore reqs, taht do not match the data model design.
We then have to write complex SQL and stored procedures and properitory
extensions and intermediate work table etc! Good thing we are not doing
some O/R auto-sql thing, but we can tune. Only one thing gorws in
someone elses hand.



This can then further complicate updates, as, for instance you may
> have updatable fields from more than one table that could be updated by the
> user. 

I have not showed you that it is simple.

You therefore need the primary key from all updatable tables

Yes you do need PKs. No magic here.

  to locate
> the correct record in the table - and the facility in the data layer to be
> able to correctly update all required tables when this situation occurs. The
> alternative is to have one bean per table but then you are doing 'lots of
> simple SQL (SELECT * FROM tbl)' rather than 'less, but much more complex
> SQL' - both can be shown to be bad for performance.
> 

Very good, you are eager, I will get you to the water.

> The alternative, of course is that demonstrated by Ted of Hibernate and
> using a true domain model 

Oh, and what kind of sql will this generate when you have complex selects?
There are dozens examples in Celkos SQL puzzels, and AFAIK none work in
any O/R or hibrenate.
Ex: A tree of exmployees boses. Newbies create a table of boss/employe,
master detail. Only boss is an employe and what if boss has a boss.
In JSP, they draw a tree that expands.
In DB we do self joins, for infinite number of levels. At the same time
I might have many to many self joins and need to get some other oture
join data out there. So some O/R is going to know my requiremtns and
write this, oh yeah. Can it paint my house while I go on vacation.
Showplan!



but then this involves always copying result sets
> to objects - which I must admit I am not over-enthusiastic of doing. 

It does not scale.

That
> said I have loaded Ted's sample from sf and it does seem very, very neat.
> 
> I would be interested in seeing an example from Vic where this technique is
> pushed a bit harder, e.g.
> 
> 1) What does Vic's technique look like when there is a large 'mismatch'
> between the database structure and that on the front-end. 

SQL on R/O, nothing better simpler/ faster or less code.
I have yet to show you R/W on compound.

This may typically
> be where the database structure is very normalised and we have a complex
> presentation view. 

My aproach is to focus on reqs, outputs, view.
Other is more to start with DB and go back to see what he can show (reqs
or no).
"my" aproach is more suitable for complex large scale. What does O/R do,
can it do insurance forms/tax forms? Not! accoring to the user comments
on news.basebeans.com/Hibreante.

I can, they can't!


This is a very possible scenario - we've all been in the
> position where the db design is already 'done' and an analyst has prepared
> screen mock-ups. How well does the basebeans approach handle this?

R/O you know, you write any sql or stored proc.
.... I have yet to show you compound updates. Good thing everyone is
doing labs so you can see it.

> 
> 2) I'm also not 100% clear on where one would put business logic in the
> basebeans design. 

What is business logic? Display the data, validate it, save it, insert.

Is it possible to also use a model - but how does the
> model get at the data and what then are the implications for performing
> other validation that requires data that may not be available in the
> presentation (i.e. form) bean?

Validate can be overloaded.

> 
> Vic - are you able to shed any light?
> 

GREAT QUESTOINS, shows you are understanding this and why baseBean has a
DAO helper is a best practice (amoung other things I showed).

Look, SQL / Stored Procedure is fastest way of doing it. Adding a
"magic" layer, is a layer, and thus slower.
The Idea of I do not know what SQL this will generate makes sense for
only simple/ small apps.
Any large/compelx app needs storedprocedures and tuning of SQL with
sometimes propriotery extensions to SQL.

Same select result can take 15 minutes or sub second, by just a few
toches to it. So select you are convinced, but not on update.

If I do not convince you, that do O/R for a complex/large app. Maybe you
come back to SQL maybe you don't.
One of the reasons I ejcet people that do not do lab is that they tend
to have theories that they never implemented. In theory, O/R has magic,
in practice, you write SQL.

hth, ask again.

(dear list, do you see now in 2 weeks we are at an advanced level, that
is why there are over 1,000 people on this list)

..V



> H.
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Geeta Ramani
> Sent: 15 March 2003 20:22
> To: mvc
> Subject: [MVC-Programmers] Question about BasePgActionC.java
> 
> Hi all:
> 
> I have been studying the BasePgActionC class and have a basic
> question.   What BasePgActionC seems to be doing is gathering all the
> "main code" in the various action classes together and cleverly using
> reflection in the dispatchEvents method to call  the appropriate method:
> say, onSaveExc, or onZoomExec, etc.  I'd like to know what the
> advantages of this approach are.
> 
> One thing I like very much about in what I think is the more
> "traditional" struts approach is the fact that the Action classes are
> separated and each achieves just one thing.  For example SaveAction
> would only worry about saving, "ListUsersAction" only about listing
> users etc.  Am I missing something basic?
> 
> Thanks,
> Geeta
> 
> _______________________________________________
> MVC-Programmers mailing list
> [email protected]
> http://www.basebeans.net:8080/mailman/listinfo/mvc-programmers
> 
>