Hue! I went to the mail archive: http://www.mail-archive.com/mvc-programmers%40basebeans.net/ - our company doesn't allow us to subscribe to news groups :(.. - and don't find any of Vic's replies there either! Nor Rick's! It's wierd that I seem to get emails from the others in the group!!! Would you please forward me the pertinent notes?
thnaks very much! Geeta Hue Holleran wrote: > 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 _______________________________________________ MVC-Programmers mailing list [EMAIL PROTECTED] http://www.basebeans.net:8080/mailman/listinfo/mvc-programmers
