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.
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 have found what it is below, but I cannot seem to find what role is plays in the three tier client-server framework.
We have the browser, web server, and database. Database and webserver are linked by the JDBC layer, but I don't see anything about where the managed bean comes into play.
I assume it gets information entered into a form for example on the front end and helps transfer to the database?
The managed beans can be linked to the UI JSF components so that when, for example, you fill out a form on a web page, the entered values are automatically assigned to the corresponding field in your Java bean. Managed JSF beans are similar to JavaBeans, but the word managed means that they can be linked directly to JSF components. Besides storing data they may also contain information about page navigation.
What is a JSF ManagedBean?
Managed Bean is just an object defined by some class that has a
name and scope.
Normally, a bean is model for your view to hold data for the components used on the view and it contains properties for it.
What role does it play in a three tier client-server framework?
From:
http://craftedsw.blogspot.co.uk/2010/05/mvc-and-multi-tier-architecture.html
In component-centric frameworks like JSF, the pages (generally XHTML) have components that are bound to Java classes (known as backing beans in JSF).
These components can be input texts, drop down lists, tables, etc, or even the entire page.
Basically each component on the page can be bound to a Java class, that would behave like a Model and sometimes Controller for these components.
The backing beans are responsible to hold the state of the components and also handle events, validation, conversions, trigger business logic, update/refresh other components, fire events, listen to events, etc.
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.
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.
i'm developing a project using JSF 2 and JPA 2 (EclipseLink 2.3).
In JSF 2 I learned that we must separate the Model from Controller and the same thing to the View (thanks BalusC).
But now with the POJO's generated from JPA, I wonder if the bean, the model, it should be the pojos now.
My view is gonna be my .xhtml pages, developed in JSF 2.0, that will interact with my controllers then in controllers call the DAO's classes and then operate in my database.
Is this right ? I mean in the concept of MVC ?
I want to do everything right, any tip ?
Thanks in advance.
"MVC" has in JSF multiple points of view. From the high level view, the Model is represented by EJB/JPA and eventually DAO/DTO (if any). The View is represented by your own JSF code (which consits of managed beans and Facelets templates). The Controller is represented by the FacesServlet.
From low level view (a further subdivision of the high level View), the Model is represented by entities or DTOs. The View is represented by your Facelets templates. The Controller is represented by your managed bean. It's basically a M(MVC)C.
Note that "POJO" is a rather legacy term from the old J2EE/Hibernate times. Nowadays, with Java EE/JPA, they're called "Entities". Yes, it are those #Entity Javabeans. Als note that some may opt to use plain vanilla DTOs instead of entities which should decouple your JSF code from the service layer. JSF should then use those DTOs as model and the service layer should in turn map between those DTOs and the real entities. This is in my opinion not necessary. EJB3/JPA2 is a pretty slick API which already minimizes a lot of boilerplate code for which you would have used DAOs/DTOs like as in old J2EE ages. With Java EE 6 and higher, there's not really a need to be able to switch of service layer to for example Spring. Everything is already well thought out and standardized.
See also:
What components are MVC in JSF MVC framework?
Difference between DTO, VO, POJO, JavaBeans?
I found JPA, or alike, don't encourage DAO pattern
Not completely right. It's usally better to avoid referencing model objects directly in the view; you can substitute them with DTO(data transfer object) that just serve the purpose of containing the data to be displayed
Well, in my opinion, this is not correct.
The XHTML pages is the view, but the controller is the JSF servlet (already provided by the framework) and what you call "controller" is actually the model (the business logic). The JPA POJOS are part of the model (the data model).
From the View you should invoke the business logic to obtain the result (as JPA Pojos) and use directly them (no transformation to DTO needed in your architecture) in the view.
Inside your model, you can organice the business logic as you whish (if you think that you need a DAO layer, very common in the industry, you can just put it).