Subject: Re: Thanks. Re[2]: Forms Beans and DAO (Best Practices)
From: Vic Cekvenich <[EMAIL PROTECTED]>
===
I am very open to having more instructors. I am planning to have an
online train the trainer, and license the 600 slides+, etc. soon to
anyone with training exp. (just jsp expertise is not enough to train)
They do go step by step from simple to advanced. I really want to make
it like a semester type class for universities. Will post to this newsgroup.
Anyway, I hope to have the muti update validation sample added to the
Struts DB sample by the following week.
V.
Rick Reumann wrote:
> On Sunday, May 5, 2002, 1:55:01 AM, Struts Newsgroup wrote:
>
> SN> Subject: Re: Forms Beans and DAO (Best Practices) From: Vic
> SN> Cekvenich <[EMAIL PROTECTED]> === My example is on the home page
> SN> and on downloads and it has full working code I teach Struts
> SN> from(ok not the latest version, I have to $ave something for the
> SN> class), and so is all the source code.
>
> Thanks for your examples. I'm going to spend some time looking them
> over really well, before I ask any more questions. I'm sure I'll
> have some so hopefully I won't be pestering you too much with them:)
>
> Side note, I have a masters in Education and have been doing Java
> and JSP for a few years now (new to Struts obviously). Maybe some
> time you might think of expanding your training sessions and I could
> help you teach more classes. This stuff fascinates me so I enjoy
> learning and teaching it. Anyway just a thought for the future:)
> Have plenty to learn to get caught up to speed with Struts.
>
> Thanks again,
> Rick
>
>
> SN> Ans 1. In DAO I have retrieve (that executes the SQL), it has a private
> SN> property of cached (disconnected) row set, a register() that returns
> SN> self, an update ( a generic update that enumerates the rows and columns
> SN> of a cachedrowset and creates and update string). It deals with updates.
> SN> If I have a different SQL string I have a different DAO. There is a
> SN> baseDAO that has dbConnect, the generic update, etc.
>
> SN> Ans 2. The methods return actionerrors and throw exceptions. (I bubble
> SN> up all errors and exceptions to the action). When a bean needs DAO, it
> SN> asks the dao to do it.
>
> SN> The questions you did not ask... if I can jump ahead... In the formBean
> SN> I say in getProertyX() { getMyDAO().getDisconectedRowSet().getString("X") }
> SN> The FrmBean also has populate, which does a { myDAO = myDAO.register();
> SN> myDAO.populate(argument1); } and populate also returns actionerrors and
> SN> throws exception. I can unit test my beans before ever touching the web
> SN> server or struts. It is best practice to Unit test before! (I use a
> SN> console app. Then you know for a fact that the erros have nothing to do
> SN> with the beans.) Then in Action I do myBean.populate(arg1); and catch
> SN> errors and execeptions in the Action. Based on those (and page dispach)
> SN> the action .... controls where to go.
>
> SN> Value objects and business objects?? Can't see that they are best
> SN> practice. I just do MVC, beans, JSP, and Controller. I would say that...
> SN> newer programmers tend to over engineer. The Bean has a dao, and all
> SN> have base classes and utiltiy helper objects (for formating and such).
> SN> Coding something for some theoretical future benefit is not what I get
> SN> paid to do. If things are needed for EJB... I think my position is clear
> SN> on EJB.
> SN> ( http://www.softwarereality.com/programming/ejb/conclusion.jsp EJB
> SN> lead a client to .NET once they figure that EJBs don't work)
>
> SN> Some say this is not best practice.... but I think it might be a very
> SN> good practice. (I invite alternatives to also post their working db code
> SN> for comparison)
>
>
> SN> V.
>
>
>
> SN> 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.
>>>>>
>>>>
>
>
>
> SN> --
> SN> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> SN> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>
> --
>
> Rick
>
> mailto:[EMAIL PROTECTED]
>
> "Sometimes you have to be careful when selecting a new name for
> yourself. For instance, let's say you have chosen the nickname 'Fly
> Head. Normally you would think that 'fly Head' would mean a person who
> has beautiful swept-back features, as if flying through the air. But
> think again. Couldn't it also mean 'having a head like a fly'? I'm
> afraid some people might actually think that."
> -Jack Handey
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
