Rick Reumann wrote:
Thanks vic for the kind words and feedback. I replied to you privately.
Rest of this email is in regard to the BaseBeans stuff I looked it.
Comments below...
On Wed, Mar 12,'03(08:51 PM GMT-0500), Vic wrote:
So consider using list/collection based beans. Ex:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bP/WEB-INF/src/war/org/apache/scaffoldingLib/base
Note that I use iBatis.com DAO, a good and fast SQL based DAO.
I've been looking at the classes from the link above and I think
what would really help me is seeing an actual web app implement the
org.apache.scaffoldingLib.base.BaseBean and see it being used for CRUD
operations. I think you had a web app to download on your basebeans.com
site but I'm not sure what to download to see this in action (should I
look at the Portal download?)
I have not release yet, so no download. It does work, but you have to
CVS out of sf.net or I can e-mail you separate. It's work in progress,
dispatch is not done yet.
(I am time slicing as is everyone doing open source. As soon as a few
more things work, I will create a early build for easier download (non-cvs))
You are welcome to use my code, its Apache license, (or develop a module
you check in to my code, for example user registration, similar to
employee list above)
For the sake of this discussion lets consider an application that would
allow a user to view Employees, insert an employee, update an employee
etc. (I'm thinking of updating my lessons, with your approval of course,
to incorporate some of these ideas, but I want to make sure I understand
them first:)
Using the List backed BaseBean idea, it appears that all the ActionForm
beans would extend BaseBean. I guess the big difference in this
approach, compared to the others I've seen documented, is your Form
beans are actually responsible for a lot more than just being holders
for simple form field properties.
My design is this: A bean should delegate DAO.
Being list/collection bean is not controversial.
Having zero-copy beans is.
This lets JSTL, Model 1, SOAP, etc. etc use beans, and it's easy to
unit test (see my abstract testIt() in bean). Also, my beans are
seriazable, so server can fail over and recover session beans, or during
development, you do not have to login.
People have called this approach simpler. When writing a complex
application, a simpler design is helpfull.
The other design is as intended by developers of Struts, for example:
http://www.eyde.net/eyde/index.do?date=20021021#213801 (a Struts blog)
or variation in Scaffolding in struts.sf.net.
There is a lot of DAO-type code in Action, and copying of fields, and
being Struts bound.
Advantage is that it can more easily display wrong data in Validation.
Explore both.
So lets take a typical example of where a user wants to update Employee
information on a form. I take it our EmployeeFormBean would have your
usual firstName, lastName fields, but then rather than pass this bean
off to be converted into a Data Transfer Object and then passed off to a
model layer to be updated, you would instead simply do something like
this in your Action:
(in the execute or dispatch method of an Action called for doing an
update):
EmployeeFormBean emp = (EmployeeFormBean)form;
emp.save(); //
To do this would we need to override the BaseBean's save() method? I
assume you also would need to provide an implementation of the BaseDAO's
update(List l) method?
I use OO, I am very comfortable leveraging OO, since OO increases re
usability and productivity. (and I am a certified OO instructor for like
8 years)
Let me just say: is a/has a, which is even on a Sun Java Cert.
Developer exam.
Or extends/delegates is the other way. So let me try to explain the
implementation.
There are things that are in common with beans, like *apples and
oranges*! If you are trained in functional decomposition, top/down,
bottom up, or structural design, you look for differences.
But OO is like genetic: Apples and Oranges are trees, grow fruit, you
can eat it, it can peel, etc. So they are 98% same!
Point is is crate a baseBean, that I extend to create concrete form
beans. Any code the I find that is common, I put in base (which I call
programing after design, since even after I created a lot of concrete
beans, I can add code and they all benefit).
Also, a bean should not do persistence, but should delegate. So I create
a helper object, a DAOImplementation. ( a DAO also has a base).
One thing is obvoice, a baseBean needs to CRUD, so it makes sense to
baseBean { public void save() { DAO.update(); }}
So each concrete bean has a concrete DAO, since each bean needs it's own
specific CRUD.
But ... I can also write generic CRUD in base DAO and baseBean, via
reflection, getMetaData, etc.
All I am saying is extend and delegate.
One more wrinkle. DB access it the slowest part of J2EE architecture, is
well known. A DAO design that works in development might not stale in
