CRUD and struts actions -- how to architect

[LeeBase]

Ok....my "procedural programmer" roots are probably going to show in
this question.

Say you have a typical data entry forum with the Create, Retrieve,
Update, Delete functions.

Do you create separate action classes and paths for each of these, or
do you create on action which looks for a parameter to determine what
action to take, followed by if/then or switch blocks with calls to
appropriate methods.

After I've typed this, it occurs to me that there is a "Dispatch
Action" class for just this sort of issue.

Still....it begs the question of "best practices" when developing with
OO software. Every time I come to a "if this, then to that, else if
this2 to that2" portion of code, I'm wondering if I'm falling back
into procedural programming.

However, I'm also unsure of the benefit of having 4 separate little
classes for handling the CRUD of a single form.

Lee

 

[Bryce]

Ok....my "procedural programmer" roots are probably going to show in
this question.

Say you have a typical data entry forum with the Create, Retrieve,
Update, Delete functions.

Do you create separate action classes and paths for each of these, or
do you create on action which looks for a parameter to determine what
action to take, followed by if/then or switch blocks with calls to
appropriate methods.

Yes, check out the DispatchAction class. It allows you to do have all
the crud methods in one action class. You define it like so:

<action
path="/myAction"
type="com.mypackage.MyDispatchAction"
parameter="action"
...
</action>

Now, your DispatchAction class looks like this:

public class MyDispatchAction extends DispatchAction {
public ActionForward save (ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) {
// Code to save here
}
public ActionForward delete(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) {
// Code to delete here
}

.... other crud actions...
}

Now, the URL would look like this:

http://localhost/context/myAction.do?action=save to save

remember the parameter="action" in the <action> descriptor? That tells
the Dispatch action to use the parameter "action" to decide which
method to call in the DispatchAction. Real handy for CRUD work..

See these links for more info:
http://www.reumann.net/do/struts/lesson3/step6
http://www.jguru.com/faq/view.jsp?EID=897290
http://www.jroller.com/comments/mrdon/Weblog/simplifying_struts_dispatchaction_and_wildcards
http://husted.com/struts/tips/002.html

After I've typed this, it occurs to me that there is a "Dispatch
Action" class for just this sort of issue.

Oh, I read this after I wrote all that stuff above. Seems like you
know what a DispatchAction is. I will leave it up there just in case
you need a quick reference, or anyone else needing the info.

Still....it begs the question of "best practices" when developing with
OO software. Every time I come to a "if this, then to that, else if
this2 to that2" portion of code, I'm wondering if I'm falling back
into procedural programming.

However, I'm also unsure of the benefit of having 4 separate little
classes for handling the CRUD of a single form.

I personally think it makes more sense to use the DispatchAction for
issues such as these. From an OO POV, your single Action handles all
actions pertaining to a particular item, or view...

 

[Sudsy]

LeeBase wrote:

Still....it begs the question of "best practices" when developing with
OO software. Every time I come to a "if this, then to that, else if
this2 to that2" portion of code, I'm wondering if I'm falling back
into procedural programming.

Considering that the actions share common elements (the form and the
data source), I like to keep everything in one class. Yes, you have
to use ifs to get the desired functionality but it's not a matter of
slipping back into a procedural coding style. It's also easier to
have all your forwarding logic in one place. It makes maintenance
easier. YMMV

 

[Bryce]

LeeBase wrote:


Considering that the actions share common elements (the form and the
data source), I like to keep everything in one class. Yes, you have
to use ifs to get the desired functionality but it's not a matter of
slipping back into a procedural coding style. It's also easier to
have all your forwarding logic in one place. It makes maintenance
easier. YMMV

I should also add that it helps to reuse actions. For example, after a
save, I like to forward to the list page.

So at the end of the save, I have:

return list(...);

 

[LeeBase]

My thanks to you and the others who responded.

Lee