I think you pretty much have it right. But . . .
Tom Holmes Jr. wrote:
I'm still a Struts newbie, but I have some confusion on the amount of classes I need to use in order to create a CRUD application.
From what I can see I need a "form bean" in order to capture the data from the JSP page. This contains the validate method which would verify some of the data from the JSP page. I also need an "Action" class/servlet that captures the action ... so if I had Add, Update, or Delete button, the Acttion class/servlet would handle the action.
Now, there is also the "bean" itself sometimes which has a 'DTO' in the name. I guess this is for "Data Transfer Object" which handles the create, retrieve, update, and delete database actions.
So, I'm a little unsure about the whole sequence of actions within struts, but here is what I want to do when I add a record.
1) calls the action class/servlet execute method
2) calls the formbean class so it can validate if the data is ok
3) if there are errors return to the page configured in struts
4) if there are NO errors
a) then instantiate the DTO class (so we can update the database)
b) Instantiate the form itself which contains data we got from the JSP page
I think this already happened at step 2.
c) pass in the "formbean" into the DTO class, so we can transer the data to the DTO from the "formbean"
To me a DTO class is nothing but a value object class. It's basically almost the same class as your form bean class -- except your form bean only uses Strings and your DTOs use real live Dates and ints (though even this rule gets broken). I usually have enough subtle differences between the two to justify separate classes, in my mind, but they might inherit from the same base class (String properties at any rate).
So in a base action class somewhere, or in some utility class, I would have a method that my Action can call to convert a form bean to a DTO or to convert a DTO to a form bean. BeanUtils.copyProperties is a method that is frequently used in this situation, but so far I have just written my own methods.
Perhaps you envision a smarter DTO.
d) call the insert method within the DTO class to file the data to the database
Sure, that's one way to do it. Another way is to have your Action use DTOs to communicate with a "manager-layer" component, which exposes CRUD operations. The manager layer component in turn communicates with one or more data access components (DAOs), sometimes using the DTOs/VOs as well. The manager layer acts as the gateway between the Actions and the data. Now you have a good place to put your business logic (keeping it out of your Actions, and out of your DAOs).
e) if there is an error, then we should return false to the action class so we can take the action as defined in the struts-config.xml file.
You can do this, but I prefer to return String or void and throw Exceptions from the "backend" to the Action class, rather than returning true or false, from CRUD methods. True or false gives you two explanations. Using Exceptions gives you an infinite number of explanations. Matter of preference I guess. But you can also take advantage of Struts' declarative Exception handling with this approach, which is a great part of Struts.
If this is correct, or sort of correct, please let me know so I can adjust my thought process. Thanks for any information you can provide.
Thanks.
Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
