I agree with Guru. After you've gained familiarity with S2, you need to
consider about what's appropriate for the particular use-cases and
business/domain model.
As soon as you start repeating yourself in your action/view code you
know its time to refactor.
Here's some of my approaches:
- For CRUD, I'll generally follow the showcase example with one action
for each 'root' domain object, with a different action method for each
CRUD operation.
- If multiple related actions have the same behaviour or dependencies
I'll create a superclass for those actions.
- I try to avoid having one superclass for all actions because they
rarely all need common behaviour. That can be convenient though.
- I try to avoid large numbers of getters and setters in the actions.
It it gets out of hand I'll create an appropriate bean.
- Generally my actions relate to behaviour or specific business objects
rather than "pages". The ease-of-use of ajax divs and 'visitor'
validation help this a lot.
- In some cases I create an S2 interceptor to inject dependencies based
on my own *Aware interfaces. The Spring and Guice plugins work well.
- As a strict rule the actions contain no business logic and know
nothing of persistence. Their role is fetch and manipulate data to/from
the business/service layer for the view.
Hope that helps.
Jeromy Evans
Raghupathy, Gurumoorthy wrote:
It all "Depends"........
If the business logic for each operation (CRUD) is complex then better
use 1 jsp and one action.
Otherwise go for the other one (one class which handles all CRUD
operations) .....
However If you have designed and developed your business layer very well
then either of the above should be fine .....
Regards
meeboo wrote:
Hey all
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
