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
