-------- 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] 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
_______________________________________________ MVC-Programmers mailing list [EMAIL PROTECTED] http://www.basebeans.net:8080/mailman/listinfo/mvc-programmers
