Subject: Re: Forms Beans and DAO (Best Practices)
From: Vic Cekvenich <[EMAIL PROTECTED]>
===
My example is on the home page and on downloads and it has full working
code I teach Struts from(ok not the latest version, I have to $ave
something for the class), and so is all the source code.
Ans 1. In DAO I have retrieve (that executes the SQL), it has a private
property of cached (disconnected) row set, a register() that returns
self, an update ( a generic update that enumerates the rows and columns
of a cachedrowset and creates and update string). It deals with updates.
If I have a different SQL string I have a different DAO. There is a
baseDAO that has dbConnect, the generic update, etc.
Ans 2. The methods return actionerrors and throw exceptions. (I bubble
up all errors and exceptions to the action). When a bean needs DAO, it
asks the dao to do it.
The questions you did not ask... if I can jump ahead... In the formBean
I say in getProertyX() { getMyDAO().getDisconectedRowSet().getString("X") }
The FrmBean also has populate, which does a { myDAO = myDAO.register();
myDAO.populate(argument1); } and populate also returns actionerrors and
throws exception. I can unit test my beans before ever touching the web
server or struts. It is best practice to Unit test before! (I use a
console app. Then you know for a fact that the erros have nothing to do
with the beans.) Then in Action I do myBean.populate(arg1); and catch
errors and execeptions in the Action. Based on those (and page dispach)
the action .... controls where to go.
Value objects and business objects?? Can't see that they are best
practice. I just do MVC, beans, JSP, and Controller. I would say that...
newer programmers tend to over engineer. The Bean has a dao, and all
have base classes and utiltiy helper objects (for formating and such).
Coding something for some theoretical future benefit is not what I get
paid to do. If things are needed for EJB... I think my position is clear
on EJB.
( http://www.softwarereality.com/programming/ejb/conclusion.jsp EJB
lead a client to .NET once they figure that EJBs don't work)
Some say this is not best practice.... but I think it might be a very
good practice. (I invite alternatives to also post their working db code
for comparison)
V.
Rick Reumann wrote:
> On Saturday, May 4, 2002, 4:55:02 PM, Struts Newsgroup wrote:
>
> SN> <[EMAIL PROTECTED]> === (great thread) If #1 is
> SN> prefered, can somone please coment as to the practical value of
> SN> the valueObject layer if one is not doing EJB. Why not:
>
> SN> myFormBean.setDAO(myDAO.retSelf());
>
> Vic, do you have an example of this at the basebeans site? I'm
> still trying to get a handle on what specifically is done in the
> business objects and what is specifically done in the DAO objects.
>
> Just a couple questions I'd like to throw out there..
>
> 1) First what methods should be in a DAO. In other words if you
> are dealing with Employees, should the DAO do everything related
> to an Employee ie. insertEmployee, getEmployees,
> getSingleEmployee, updateEmployee ?
>
> 2) What should the methods in the DAOs return? Are they returning
> ResultSets to the Business Objects? Collections of beans?
>
> Thanks for any more feedback.
> --Rick
>
>
> SN> This allows me to unit test the dao (DAO in my case has a SQL string and
> SN> CachedRowSet). This allows me to unit test the bean, without Struts or
> SN> action classes.
> SN> It also allows me to re-use the bean outside of Struts (ex: SOAP, so VB
> SN> applications can read it on client side).
>
> SN> Vic
>
> SN> OT: I think anything that does not allow you to unit test DAO or Bean
> SN> without action class is not best practice. Anything that assumes you are
> SN> using EJB is not best practice. IMHO
>
>
>
>>>I see what you're doing and agree it seems easier.
>>>
>>>But coupling the form beans to the DAO's so tightly I wouldn't call a best
>>>practice. Here is another approach:
>>>
>>>
>>>- Have the DAO's return Value Objects. But then have a setValueObject() on
>>>the form bean so you can store the entire value object in it.
>>>
>>> First, in your action class, do something like:
>>>
>>> myFormBean1.setValueObject1(myDao1.getValueObject1());
>>>
>>> Then either,
>>>
>>> 1. Have your get/set methods for the form bean properties use the
>>>value object for storage internally, like:
>>>
>>> // in the form bean.java file
>>>
>>> private ValueObject valueObject1
>>> public void setValueObject1(ValueObject val1) {
>>> this.valueObject = val1;
>>> }
>>>
>>> // Note: no property1 field needed!
>>> public String getProperty1() {
>>> return this.valueObject.getProperty1();
>>> }
>>> public void setProperty1(String property1) {
>>> this.valueObject.setProperty1(property1);
>>> }
>>>
>>>
>>> - or -
>>>
>>> 2. Have the setValueObject() in the form bean deconstruct the value
>>>object and store its components in the form bean
>>>
>>> // again, in the form bean.java file
>>>
>>> // Note: no valueObject1 field needed!
>>> public void setValueObject1(ValueObject val1) {
>>> this.property1= val1.getProperty1();
>>> }
>>>
>>> private String property1;
>>> public String getProperty1() {
>>> return this.valueObject.getProperty1();
>>> }
>>>
>>>
>>>Another alternative would be to put a "facade" in front of multiple DAO's
>>>to simplify the actoin class and decouple it from the back end data
>>>sources.
>>>
>>> // In MyAction.java
>>>
>>> int id = 123; // id is key into back end systems
>>> MyFacade facade = new MyFacade();
>>> MyFormBean formBean1 = facade.getFormBean(id);
>>>
>>> // Then in the facade, have something like:
>>>
>>> public MyFormBean (int identifier) {
>>>
>>> MyFormBean mfb = new MyFormBean();
>>>
>>> MyDao1 dao1 = new MyDao1 ();
>>> mfb.setDao1Vals(dao1.getVals(id));
>>>
>>> MyDao2 dao2 = new MyDao2 ();
>>> mfb.setDao2Vals(dao2.getVals(id));
>>>
>>> MyDao3 dao3 = new MyDao3 ();
>>> mfb.setDao3Vals(dao3.getVals(id));
>>>
>>> return mfb;
>>> }
>>>
>>> This decouples the FormBean and the Action class from the structure
>>>of the DAOs and the back-end sysems.
>>>
>>>
>>>
>>>Given all this, I like the first approach above the best.....
>>>
>>>
>>>FWIW -
>>>Kevin
>>>
>>>
>>>
>>>
>>>
>>>Mike Duffy <[EMAIL PROTECTED]> on 05/03/2002 11:50:37 AM
>>>
>>>Please respond to "Struts Users Mailing List"
>>> <[EMAIL PROTECTED]>
>>>
>>>To: [EMAIL PROTECTED]
>>>cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
>>>Subject: Forms Beans and DAO (Best Practices)
>>>
>>>
>>>I am pre-populating a form with information from a data base.
>>>
>>>Is the following procedure acceptable, or is there another procedure
>>>that would be considered a "Best Practice"?
>>>
>>>Instantiate the form bean in the action class.
>>>
>>>Instantiate one or more DAO objects in the action class.
>>>
>>>Call methods in the DAO objects that would take the form bean as an
>>>argument and fill up the necessary fields.
>>>
>>>I understand the need to keep layers separate; however, if I am just
>>>trying to fill up the fields in a form, it seems unnecessary to have
>>>the DAO objects return data objects and then call a series of
>>>"get/set" methods to take the data from the data objects and put it
>>>in the form bean.
>>>
>>>Thanks.
>>>
>>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
