Hi Niall,
I not sure I agree with you, although you have som good points.
When looking at the MVC pattern we can easily identify two of the elements,
namely the view (jsp) and the model (usually persistent object)...
However, where is our controller??? As you point out, in the struts context
the controller would be (partly) the Action, and probably some kind of
Facade pattern towards the Model...
However, in the classic sense of the MVC, the Controller should be reusable
between many applications, and the Action dependence to the Servlet API
doesn't (strictly speaking) make this possible.
The solution to this is ofcourse to build a "inner" Controller, with close
ties to the Model, such as an Facade or a (none Servlet specific) Command.
However, I Feel that this just introduces another level of abstraction, and
this abstraction should/could be made by the Action
To give you a clue of the granularity of my Actions I give you the following
example, please comment and tell if you think I have to much Model in it,
and if, how to avoid it.
This is probably not the best example, but here it comes...
My Current Project deals with financing...Users has to LogOn to the System
Model : User
Controller: LogOnAction
The Action makes use of an UserModelFacade. The UserModelFacade has a
getUser(String uname, String pw) method...
Pseudocode:
User theUser= UserModelFacade.getInstance().getUser(name,pw);
if(theUser==null)
return(mappings.findMapping("failure")
request.getSession().setAttrubute("myUser", theUser);
return(mappings.findMapping("succes")
This is the basic architecture and strategy we will be using in the
development.
When I said that this was a bad example, its because it only access the
Model once...
But some of our processes is more complicated than that...
Sometimes we need to
get the CurrentUser
get other possible customers in the household
get number of cars in the household
get the "new" car
make a finance calculation based on the above
The following will result is 20-30 lines of code in the Action. LOC's I
would like to be able to reuse...
I haven't heard of Cactus or HttpUnit before this thread, and I will surely
look into them (souds like great tools)
nice thread btw ;-)
regards Mikkel
-----Original Message-----
From: Niall Pemberton
To: [EMAIL PROTECTED]
Sent: 17-05-2001 17:11
Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm
I don't agree - Actions are part of the controller in MVC and need
access to
the servlet API to do thing such as retrieving and storing objects under
the
appropriate context. Sounds to me like 1) Your using the wrong tool and
2)
You've put your Model in the Actions.
1) Cactus is a simple test framework for unit testing server-side java
code.
It uses JUnit and extends it. It's primary goal is to be able to unit
test
server side java methods which use Servlet objects such as
HttpServletRequest, HttpServletResponse, HttpSession etc.
http://jakarta.apache.org/commons/cactus/
HttpUnit is a Java library for the automatic stimulation and testing of
web
applications - which is supposed to be complimentary to Cactus.
http://sourceforge.net/projects/httpunit
I haven't used these tools, but I'm about to download them and try them
out.
Also I know Struts is in the process of setting up Cactus test suites so
it
sounds like is more appropriate than JUnit for this environment.
2) If you succeed in separating your Model from the controller then you
should end up with a set of small Action classes. Testing your model
outside
of the servlet enviornment should then be pretty straight forward. This
is
what we've done and it works well.
Niall
> -----Original Message-----
> From: Mikkel Bruun [mailto:[EMAIL PROTECTED]]
> Sent: 17 May 2001 10:02
> To: '[EMAIL PROTECTED]'
> Subject: Suggestion:Taking the Servlet out of Action and ActionForm
>
>
> Hi guys,
>
> Here's a little design suggestion. I don't know if you have already
> discussed this.
>
> As we all know Action and ActionForm makes use of parts of the Servlet
API
> (HttpRequest).
> This ties the execution of Action and ActionForm to a servlet
enviroment.
> This is not bad, but (imho) it isn't good either...
>
> * We are not able to test our Actions in other enviroments (JUNIT for
> instance)
> * It's not possible to port our Action and ActionForm implementations
to
> other types of applications (applet, console)
>
> A couple of month ago I implemented my own Model2 framework that
> worked with
> a socalled RequestContext.
> The RequestContext contained three HashSet's, representing
> request-, session
> and applicationattributes
> In the Servlet's service (post/get) method we would populate the
> RequestContext with all request, session and applications attributes
and
> pass it along the our viewvalidator (in this case an ActionForm
object),
> that would extract the needed parameters and react to them (this
> could still
> be done with reflection as in struts).
> Any output from the validation would then be placed in the
> RequestContext's
> Collection (as a proxy to the *real* HttpRequest, HttpSession, etc,
> objects).
> If the validation was succesful the Servlet would then pass the
> RequestContext to a Command (or Action). The command would then
extract it
> needed parameters and work on them.
> Once again, output would be place in the RequestContext's
> representation of
> Request, Session and Application.
> When the Command (or Action) was completed, the Servlet would iterate
> through the RequestContext and place all the attributes into their
> respective scope.
>
> The important point here is that the RequestContext wasn't tied to the
> Servlet API, although it could be initialized with HTTPRequest as
> parameter.
>
> By doing the above we were able to create validations and actions that
we
> could easily test and reuse.
> What we usually did was that we created JUNIT testcases where we
created
> instances of RequestContext and passed it to our Actions and eveluated
the
> return values...These JUNIT cases could then be run from anywhere.
> We actually had our deployment done by Ant, and our deployment
> scripts would
> run all our testcases before deploying...
> We could actually test "all" of our application from the
commandline...
>
> Just my two cents...
>
> Mikkel Bruun
>
>
