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.
Related
I'm building a Java web app that follows the MVC model.
I have a number of JSP pages that act as views for the respective objects in the DB, for example product_details.jsp.
I plan to use URLs like product_details.jsp?id=123, and since I have quite a lot of View pages, I was wondering if it was necessary to write a servlet for each of them that only retrieves data from a DAO or if there was a clean way to call a DAO from inside the JSP itself.
Would this violate the MVC model even if no controller is needed? What would be the best approach?
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.
Could anyone suggest the best approach for sending data from controllers to service layer ?
I have UI <--> Controllers <--> Services <--> DAOs
I have models (or commands) to hold the data that user inputs in the UI to pass to controllers
I thought of creating models in controller layer , but don't want to pass them directly as service layer then depends on controller layer.
Do you suggest creating models in service layer and use them in controller layer ? But in this case these models will be used by jsps to serve data to the user ? is that ok ?
Could anyone suggest the best way in java to design the mvc layer shown above ?
Thanks
Ramesh
It's not necessarily wrong to serve domain model object directly to the UI layer, it's just that you tend quickly to run into a few common problems:
the view screen only needs a small subset of the model
certain fields like for example User.password you never want to send to the view layer
the domain model can contain loops, meaning object navigation paths in the object graph that go back to the initial object. This cannot be serialized correctly
lazy initialization exception on the domain model caused by detached objects
The common pattern to solve this is the DTO pattern, see here the description by Martin Fowler.
The common way to to it in larger applications is for the controller to send and received DTOs, and then do some mapping if needed to convert them into domain objects, this can be done for example with the Dozer mapping library.
On a smaller application this might not be justifiable, specially if you haven't encountered the problems mentioned above, although these tend to show up frequently.
Controllers take input from UIs and forward (hence the name Controller) the request to appropriate Model in tradional MVC pattern. But since you are using Spring MVC why not create your model objects in Spring context and use them is your service layer? You can use #Resource or #Autowired in service layer. Besides, if you want to reuse model objects you can easily do that because this way they are not locked into a particular layer. For eg., web service using your context.
Maybe others have a better way to do this.
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.