Re: Question about BasePgActionC.java

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]]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
> >
> > _______________________________________________
> > 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