I am studying the Struts2 in Action and come to know that Controller in Struts 2 is FilterDispatcher and Model is Action.
But previously I knew that Action and FilterDispatcher both are Controllers and Struts does not provide support to Model layer. Which one of the above is wrong?
I would say that FilterDispatcher is a FrontController and Action is both Model and Controller in one class.
Actually Struts2 Actions are controller delegates. And Struts2 provides a valueStack on the View layer which has an Action on top of it, and if you want to use a pseudo-model then action should implement ModelDriven interface.
You should also note that Struts2 actions are simple POJOs managed by Struts2 container. This is a bit different in the MVC point of view, also known as MVC Model2. For example, the description of the model given by wikipedia:
The central component of MVC, the model, captures the behavior of the application in terms of its problem domain, independent of the user interface.[5] The model directly manages the data, logic and rules of the application.
From this point of view a Business Model is defined separately from the View Model and often being managed by Persistence layer. Struts2 controller works with the View Model via its delegates.
The View can be any output representation of information, such as a chart or a diagram; multiple views of the same information are possible, such as a bar chart for management and a tabular view for accountants.
In Struts2 the View is a Result returned by the controller in response object. Struts2 can use different result types and templates to produce a response.
The Controller, accepts input and converts it to commands for the model or view[6].
Struts2 uses a request for the input, which is handled by the Action to find appropriate delegate, which can work with the View Model directly or use a Service layer.
In Struts2 an Action is a Controller, it's a simple POJO which is also a Model.
Struts2 can help you with the Controller via ActionSupport and presenting a View, it's also pushes Action to the valueStack to have access from the View. You can design a Model via associating your Business Model with the View Model.
Related
In my current project we use mvc layers
- we have ajax js app as view, controllers, models, service layer as bl, orm as dal.
My question is what exactly are the controllers responsible to, for example my js app has a view that shows all the names of the items I own,
Should the controller call the service layer, retreive all the items, map them to their name and send to the view or - should the controller return all the items to the view and the view would take only the name?
In conclusion, what kind of logic should a controller of ajax app have? Should the js app proccess the data or the controller ? Or even the service layer.
Thanks
You have correctly identified the role of the controller as sitting between the view and the model.
This question is subjective, with the answer depending on opinion. As a rule, the less the view has to do the better.
The more post I read the more confused I got....
In spring MVC:
What I got was this. View is just your jsp. Dispatcher Servlet is your controller. It handles the request and direct to appropriate actions. Then #Controller (some class) is also your controller but under the same class (from tutorials point) you can have #modelattribute which is your model object. First, I thought the purpose is to separate model and controller (that's why we use MVC) so why is your business logic can be the same class as your controller? So what exactly is Model and Controller in Spring? can you have two controllers? (#Controller class and dispatcher servlet) Models in spring are from #modelattribute objects or the beans from business logic?
Views are not just JSP, but any view technology, such as JasperReports
I thought the purpose is to separate model and controller (that's why
we use MVC) so why is your business logic can be the same class as
your controller?
You business logic should go in service classes, which are referenced by controllers. You can put some simple validation in entities themselves.
So what exactly is Model and Controller in Spring?
Model is a map of any data that your view might need. It can contain Entities, or Form Backing Objects or Strings or anything you want.
DispatcherServlet is your front controller, not your regular controller.
Controller is a class with Handler Methods that are called due to HTTP requests, and generally collect model data and pass them to a view.
can you have two controllers? (#Controller class and dispatcher
servlet)
You can have as many controller as you want. The more the merrier! Generally one front controller is enough.
Models in spring are from #modelattribute objects or the beans from
business logic?
#ModelAttribute is a special, ill-documented, poorly-understood annotation that shouldn't worry about until you understand the basics.
Model is a map of anything you want. It is all of the data that the view needs to do its view thing.
I want to know data flow in the Struts 1.2 framework .
I found Different components like
struts.XML
action class
form class
Vo class
Dao class
After studying a lot I came know that dao act as communicator with database. One thing I can't understand is the form concept of struts and what is the vo class means? How vo class is populated using the value given in the front end.
Please help.
Well todays world belong to new generation of MVC frameworks like Struts 2, Spring MVC etc which helps developer to focus on their core work in cleaner,modular and scalable style. If you are learning better to start with them. But if you are working on some legacy project then it makes sense. I used to work on struts 1.2 9 years before. Here is what i recall
Major components are Jsp(View), Action(controller), Form(Model/backing bean for form populated data ).
When you submit the form on jsp, request goes to web.xml where it founds the mapping for Struts 1.2 front controller, This controller internally resolves the request path mapping from struts.xml and inititates the action. Front controller also populates the form bean from request parameter and supplies it as mathod parameter to called action method. Main point to remember is there will be single instance of action class per container, so it should be stateless. There are different kind of actiona which you can explore further.
VO are the value objects . Some calls them domain objects(DO)/Data Transfer Objects(DTO)/Java beans.
Basically they represent the represent the persistent entity in Database and act as a carrier.
DAO/Service layer is not a part of struts framework. Its your business layyer. Basically struts work ends at action class beyond which it further delegates the call to service layer.
What is the difference between the push & pull models of MVC?
Is Struts2, Spring MVC Pull based?
According to Struts2 Interview Questions and Answers
Struts2 is a Pull-MVC based architecture, in which all data is stored in Value Stack and retrieved by view layer for rendering.
Specifically:
In case of Push-MVC the data (Model) is constructed and given to the
view layer by the Controllers by putting it in the scoped variables
like request or session. Typical example is Spring MVC and Struts1.
Pull-MVC on the other hand puts the model data typically constructed
in Controllers are kept in a common place i.e. in actions, which then
gets rendered by view layer.
The concept of push and pull refers to what the server does in relation to the client. In a "push" application, a server is pushing or sending data to clients at it's own initiation. In a "pull" application, the server is pulling or waiting for and receiving messages initiated by clients.
A good explanation is given here mvc-pattern-its-importance-push-pull and here pull-vs-push-mvc-architecture
Struts1 and Spring both use Push MVC. This question might be helpful spring-mvc-complex-model-population-from-multiple-sources Struts2 uses Pull
Struts2, Play! and so on are all kinds of pull model implementations of the MVC pattern.
Terms "push" and "pull" refer directly to the type of implementation of the observer pattern used between View and Model. As stated in GoF Observer pattern explaination, we have:
At one extreme, which we call the push model, the subject sends observers detailed information about the change, whether they want it or not. At the other extreme is the pull model; the subject sends nothing but the most minimal notification, and observers ask for details explicitly thereafter.
This means that the implementation of push model requires that View and Model are implemented using the same language and they are executed in the the same environment. Good examples of this kind of implementation are Javascript single page applications, in which View and Model components execute inside the browser and a framework, i.e. Backbone, provides MVC (a.k.a. Observer) mechanism. Often, Model component interacts with some kind of server API, to persist and get persisted datas.
On the other hand, pull model lets you implement MVC using different technologies for View component, and Controller / Model components. In this kind of MVC, there is not an explicit use of the Observer pattern and View interacts exclusively with Controller. View component, which usually executes into the browser, sends to Controller component request of model's updates or model's state. Usually requestes are implemented using HTTP protocol. This kind of implementation requires the use of some type of "augmented HTML scripting language", such as JSP, which allows to create automatically the link between View and Controller.
Sorry .. I dont think that struts 1, struts 2 and spring MVC can be taken as PUSH MVC ..
as both of all frameworks use a front controller[Filer class for Struts , And Controller Listener for Spring ] defined in their respective deployment descriptor. Now both of all these frame work save the form data in their respective bean[Or model] object using that controller by reflection.
Now from our Action Controller we can receive the bean object and will get the values but in the front controller where the bean object[or model] is actually generated set the value in their resperctive field by using request.getParameter(param) or request.getParameterValues(param) methods internally.. So this can be considered as PULL.
So as per my thinking we can say that These framework can use two layers namely PULL layers used by end programmer and PUSH layers used by framework base classes.
We are making a rather large Swing application which has to implement the MVC pattern.
The application currently looks like this:
There are quite a few views. They are created in a hierarchical manner where one main view contains (and creates)
several views which all contain their own set of sub-views, etc. Each of these views retrieve information from the model
independently from the other views, by calling the models static methods when necessary.
There are also quite a few controllers which are all totally separated from each other. Each controller
belongs to a view. Each view creates its own controller, and adds the controller as a listener to user input.
The controllers receive events from the views and then modify the model through the models static methods.
When the views dispatch events which do not affect the model, but only affect
the views, the views take care of these events themselves - without informing the controllers about the events.
That is, the controllers are totally unaware of the views, and the controllers purpose is only taking care of the manipulation of the model.
|EDIT: the controllers are currently attachments to their views; they only contain logic for event-handling. That is, the controllers are not components themselves, and do not contain components. They are implemented in the same manner as the following example: MVC example |
The model in the application is very passive, and does not even have listeners (it represents a database).
It receives updates from the controllers.
In this example, the views own the controllers. Would it be better in the general case if the controllers owned and created the views, and if one let the views be unaware of the controllers, instead of the opposite? In that case, why?
How would this be designed? If not, is there a better design in which the controllers are still unaware of the views? Or perhaps, is the best design neither of them?
EDIT:
As stated in the Original MVC definition:
the line "The View takes responsibility for establishing this intercommunication..."
seems to indicate that the view creates the controller, or at least has the initial reference to the controller, and not vice versa.
So this is at least a possible way to do it (it is a valid MVC pattern), but the main question remains; which is better, and how would the best design look like?
Especially when dealing with many controllers that are closely related to their respecive
views?
EDIT: Another example of a view which references a controller: Oracles example
As seen in this outline, the controller has the model and the view(s). Any sub-views are managed by the respective parent view. Sub-views may forward events to the parent as discussed here. There's a simple example here with more links.