aspose file tools*
The moose likes Struts and the fly likes Disucssion about MVC Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Disucssion about MVC" Watch "Disucssion about MVC" New topic
Author

Disucssion about MVC

Saurabh Agrawal
Ranch Hand

Joined: Oct 07, 2003
Posts: 244
Hello folks,
I would like to know from you guys that in MVC model on which struts is based, where would you put Action Classes as ? I mean to ask does it come in MODEL/VIEW/CONTROLLER ??
I was asked this question in an interview and i said they fall in Model category ?
So please let me know where do thye fall exactly? Also let me know if Action Servlet is our controller, then does every request is first propogated through it.As far as i know every request seeks a mapping thrugh struts-config.xml , then how does Action Servlet plays its role.

Saurabh


Success is not doing extraordinary things but doing ordinary things extraordinarily well.
Sumit David
Greenhorn

Joined: Oct 23, 2003
Posts: 10
Hi

If you remember the servlet-mapping tag from web.xml, every request goes to the controller servlet (ActionServlet), which looks up the struts-config.xml for possible Action instances to execute and then ActionForwards.

I guess Action instances fall in the model part of the MVC architecture.

Sumit


SCJP 1.4
sasi kala
Ranch Hand

Joined: Dec 17, 2004
Posts: 68
hi,

as far as i know
Model -- business logic will fall under model category. (ejbs, javabeans)
View -- jsps and html's fall under view category

As you said each request first comes to ActionServlet and then goes to corresponding action.

action instances fall between model and controller.

Hope this helps u
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Actions are not the Model of MVC. The Model holds state. Action classes are not supposed to hold state.

Actions are part of the Controller. They are not the Front Controller, but they still have many Controller behaviors. Actions update the Model and choose which View to show next.

You could probably search the forum here for past rants on how Struts fits (and doesn't fit) into MVC.


A good workman is known by his tools.
Merrill Higginson
Ranch Hand

Joined: Feb 15, 2005
Posts: 4864
I agree with Marc. The action class definitely falls the the controller category. It's purpose is to pass information from the view to the model and back again.

For this reason, I believe action classes should do very little but receive input from the view, decide what to do with it, reference objects in the model, and direct back to the view.


Merrill
Consultant, Sima Solutions
Anselm Paulinus
Ranch Hand

Joined: Sep 05, 2003
Posts: 389
I agree with Marc and Merill;
Your view is your JSP; the model is the bean which holds your data, while your action class along with your struts-config make up your controll.
Jason Menard
Sheriff

Joined: Nov 09, 2000
Posts: 6450
Just to add a couple of points... Struts implements many design patterns, but one of the more important ones is the command pattern. Actions are Command objectes as described by this patter, and as has been mentioned, they are very much part of the Control. The "controller" is the ActionServlet, although it delegates much of its responsibilities to the RequestProcessor. So with the exception of ActionForms and the taglibs and probably a few others, the vast majority of the Struts package falls squarely into the realm of the control.

But what about ActionForms? This seems to confuse people sometimes as to where they fit within the whole MVC thing. Although some people think of them as part of the control or model, ActionForms are part of the View. Validation tends to muddy this a bit, as people often (mistakenly?) perform business validation on ActionForms, but as they are so tightly coupled to the view components, the only conclusion to be drawn is that they are part of the view.

Getting back to the Actions, the trap many people fall into with these is an issue of tier leakage. That is, business logic all too often finds its way into the Struts Actions. A Struts Action should really be pretty concise and not have all that many lines of code in it. If people get into the habit of using Business Delegates, they can generally avoid the problem of tier leakage to a greater extent. Each Business Delegate method likely solves a use case, making it so that you can almost slap on an entirely new controller and framework to your application with relative ease.

Assume our application is a forum application such as JavaRanch. Our user wants to view a particular thread from a list of threads. A typical architecture might go something like this....

1. User selects link to a thread he wishes to view and submits. Thread id is submitted in the request.

2. ActionServlet gets a hold of the request and hands it off to the RequestProcessor who will decide what to do with it.

3. The RequestProcessor sees that the user wants to view a thread, determines that the correct command to delegate to is the ViewCommandAction, and hands off the request to that Command.

4. The Action grabs the thread id. It gets a hold of a ForumThreadDelegate and passes the thread id to its getThread() method, along with maybe some user information.

5. The getThread method of ForumThreadDelegate gets a hold of a Data Access Object (DAO) which for lack of a better term I'll call ThreadDAO. The Delegate in turn calls the ThreadDAO.getThread() method passing the thread ID.

6. The ThreadDAO.getThread() method accesses the database and constructs a Thread object from the data in the database that corresponds to the requested thread, if it exists. This Thread object is returned

7. Now the Delegate inspects the returned Thread and compares it to the user information that was passed in to determine whether or not the user has permission to view the requested thread. Assuming the user is allowed to view the thread, the Delegate returns the Thread object back to the Action.

8. The Action now has a Thread object. The Action doesn't want to give this entire object to the view however, and instead needs to assemble an ActionForm containing data from the Thread thatthe view needs. It uses an Assembler object to do this, which we will call ThreadAssembler. The ThreadAssembler has a method called assembleForm taking an ActionForm destination and a Thread source as arguments.

9. The ThreadAssembler.assembleForm() method takes the pertinent data frm the model object, Thread, and populates the ActionForm with it. The ThreadAssembler also has another method, assembleThread() which goes the other direction, populating a Thread object based on the contents of an ActionForm, but we're not using that method right now.

10. The Action now has an ActionForm in the proper state to be used by the view, so it can now use the ActionMapping to find the correct ActionForward and return it to the RequestProcessor.

11. The user will now be forwarded to a view of the thread he has selected.

Our Action populated an ActionForm because I made the assumption that for whatever reason the thread is presented to the user within the context of an HTML form that he or she might input data into. A little hoky to be sure, but it illustrates all the points I wanted to. If a form was not displayed in the view, I could have either populated some kind of a Thread DTO, or if it was appropriate, return the Thread object itself.

So this kind of illustrates how all the parts of the MVC work together with each part doing only the work it should be doing. It helps to further break things down into various tiers such as the View Tier, Control or Application Tier, Business Tier, and Persistence Tier. Your JSPs and ActionForms fall into the view tier, all the rest of the Struts stuff generally falls into the control tier, your business delgates, model, and other business objects fall into the business tier, and your DAOs are part of the persistence tier. If you think in terms of these tiers or layers, you may find it easier to avoid tier leakage and maintain a more sound design.
[ March 20, 2005: Message edited by: Jason Menard ]
kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1379
Hi Jason, I think ActionForms are part of the Model. Because it's FormBean.
Jason Menard
Sheriff

Joined: Nov 09, 2000
Posts: 6450
Originally posted by kri shan:
Hi Jason, I think ActionForms are part of the Model. Because it's FormBean.


A section in some of the Websphere documentation breaks it down pretty good in a discussion of Struts and MVC:

Model
The model is the business logic, which in most cases involves access of data stores like relational databases. The development team that handles the model may be expert at writing DB2 COBOL programs, or EJB entity beans, or some other technology appropriate for storing and manipulating enterprise data.

View
The view is the code that presents images and data on Web pages. The code comprises JSPs and the Java beans that store data for use by the JSPs.

Controller
The controller is the code that determines the overall flow of the application. It comprises one or more Struts actions, configuration files, and servlets.


That document does go on to specifically break down some of the specific Struts components that go along with each layer in MVC.

As a concise description of the view, I think the above is pretty good. It points out that not only is the view the JSP or some other type of presentation, but also the view includes those Java Beans whose sole purpose is to provide the view with data. Under such a definition, ActionForms would certainly have to be considered part of the view.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Disucssion about MVC