Hi Geeta, Vic's emails have not been making it to the recipients of the list - but have made it to the news server and news.basebeans.net - he has responded to the question(s) below - and Rick (Reumann) has also asked a pertinent question as well.
I have emailed Vic to let him know about the problem with his mails and also the fact that replying to a mail to the group does not automatically go back to the group (which I think it should) - I think the latter is a setting in the mail manager for the group - which I guess Vic may change in time. H. -----Original Message----- From: Geeta Ramani [mailto:[EMAIL PROTECTED] Sent: 17 March 2003 12:18 To: Hue Holleran Subject: Re: [MVC-Programmers] Question about BasePgActionC.java Thank you, Hue, for your detailed reply. I guess I see what you are saying.. however I am not convinced this approach would work well for me. Maybe the current example we have does not illustrate well the advantages - to me it seems like (what I see as) the loss of the simplicity of the framework is not offset by the gains.. Since Vic has not responded to either my question or your reply, I guess I'm going to look into Ted's approach now.. :) Thanks again! Geeta 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. > > 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 - otherwise you > end-up doing a lot of complex joins in SQL to get the result set you need > for DAO. 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. You therefore need the primary key from all updatable tables 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. > > The alternative, of course is that demonstrated by Ted of Hibernate and > using a true domain model but then this involves always copying result sets > to objects - which I must admit I am not over-enthusiastic of doing. 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. This may typically > be where the database structure is very normalised and we have a complex > presentation view. 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? > > 2) I'm also not 100% clear on where one would put business logic in the > basebeans design. 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? > > Vic - are you able to shed any light? > > 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 _______________________________________________ MVC-Programmers mailing list [EMAIL PROTECTED] http://www.basebeans.net:8080/mailman/listinfo/mvc-programmers
