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.
Related
I have simple java project with separated DAO classes, Controllers and Models.
First of all, who should care/use DAO instances? I have DAO interfaces and classes that manage queries to DB, but the actual instances of this DAO classes should be in Controllers or Models?
Then, the actual computation of what the controller receives from the View, where should I manage it? Should I pass all the inputs to the model and create a method that manages and calculate the result and then return it to the controller? Or the controller should have this method?
I don't find clear answers on the internet regarding this aspect of MVC.
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.
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.
How are models and DAOs supposed to interact? I'm in the process of putting together a simple login module and I'm unsure where to put the "business logic." If I put the logic with the data in the model, how would I access the logic?
Currently, I have:
A controller that receives form data
A model that is a simple reflection of a db table
A DAO that using hibernate performs a simple select query, based on the
form parameters received by the
controller.
The controller has to find/load the business object matching the request and execute it. The Strategy Pattern is useful in this. The business object on its turn has to get a handle of the DAO and the model to do the process.
E.g. (pseudo, inside a front controller servlet)
public void process(request, response) {
View view = new View(request, response);
Action action = ActionFactory.getAction(request);
if (action != null) action.execute(view);
view.navigate();
}
Put it in the controller. Controller is like a heart of your application where most of the logic is written.
It's not good to put the business logic at Model Level.
You might want to take a look at some of the answers to Best designs for breaking down business logic and data layer when they seem to overlap?
A typical layering would be like this:
Controller
Model
Business Layer
Data Layer (DAO)
The model would contain both the business and data layers while keeping those layers loosely coupled to the extent that makes sense. The controller would access the model, which in most cases should be the business layer. It's preferable that the controller not have direct access to the data layer, but it happens quite a bit in smaller apps.