CODEWITHSUNDEEP
springjspspring-mvccontroller
Xelian
Xelian

Reputation: 17198

Spring best practice to separate model from view in controller and jsp?

Is it a good practice to use Spring Controller class(with @ModelAttribute) and the jsp to prepare model at the same time or the model has to be prepared only by Spring and the view from the jsp? The idea comes from this topic . I have a Controller class:

@RequestMapping(value = {"", "/"}, method = RequestMethod.GET, params = "mode=create")
public ModelAndView showCreatePage(@ModelAttribute("createForm") ApplicationCreateForm form)
        {
       return customMethod("some string");
}

and in my jsp I have:

<jsp:useBean id="createForm" scope="request" class="com.example.ApplicationCreateForm"/>

I do not need to populate the form with the information to be present to the user all fields are empty.

So from what I uderstand I have been declared ApplicationCreateForm bean twice, with the same scope - request.

Is it a good design practice to use both at the same time? Is there a reason for that? Does the second declaration(in jsp) give me more power, for example to override the model or it is complete unnecessary? Does the second declaration overrides the first one when both are present?

Upvotes: 1

Views: 1957

Answers (4)

Anuj Yadav
Anuj Yadav

Reputation: 990

There are many things wrong with this implementation.

Is it MVC?

If JSP know about Model, why do we need controller. Lets remove the routing engine and use JSP directly to consume Model. But then the application will be monolithic. I believe you do not want that. We have two major flavours of MVC. In both, controller is the front facing object. It receives the command, interprets it, works with data layer and gets Model. If required the Model gets converted into a viewModel and then this object is passed to the view.

Why viewModel?

Say we are implementing paging on screen. We are showing list of persons. Person is your model here but your view also need to know page number, page size etc. Your model thus may not fit directly in this case.

Say we need data from multiple tables to shown on screen. This data is related in some way. Now will you pass separate model objects to view and let it do all the business logic? Ideally no.

Should not the design support DTO or ViewModel or Commands and Queries?

We want our application to be designed properly. As stated above we need to send data to view or clients (REST) after processing. Processed data may not map to you domain until unless we are just creating a CRUD stuff. What if you want to implement CQS or CQRS?

Where is separation, where is SOLID?

If my view is performing business logic then where is 'S'? If view knows about model and need to be changed in slightest of changes in model then where is 'O'?What if I want to separate queries from command (CQS) and scale the two things separately?

To conclude I would say, yes you can do this but it is not good if you are developing a decent size application or you think it will eventually be one. I have seen people using model entities starting from ORM, to controller to view. It will work but the question is do you want a monolithic and tightly coupled application. As per my experience the presentation logic (view) has very different logic and need of data in comparison of controller and same goes for your data access layer.

Upvotes: 1

A N M Bazlur Rahman
A N M Bazlur Rahman

Reputation: 2300

Since spring comes with the concept of making things loosely coupled to make your code more testable, you should always keep in mind that separation of concern is your priority. So it is always the best practice to prepare your model fully in Controller, not in views.

Keep thing simple , make your controller responsible for preparing your model, and keep your views to display the model only.

So, a big NO to your question. The second declaration isn't going to make you powerful, rather help you to be tied up.

Upvotes: 0

user3247727
user3247727

Reputation: 149

By defining you are creating tight coupling between your view and class com.example.ApplicationCreateForm, using spring mvc you achive loose coupling between your controllers, view and model it might happen that you change you model name but you still have same properties in it which might be enough for view, in above case you will need to update your view but it won't be required in case you are using Spring MVC.

Upvotes: 0

Vojtech Ruzicka
Vojtech Ruzicka

Reputation: 17075

I think you should prepare your model fully in spring controller. Then view should be as passive as possible, ie. only showing model attributes received from controller while having no further knowledge about application logic. This approach gives you clean separation of concerns and you view is as independent as possible and can be easily switched for different view technology - eg. thymeleaf or freemarker templates. The whole idea of MVC is to separate presentation layer and by leaking business logic to view you create unnecessary dependencies.

Your view should be as simple as possible, as the logic leaked to view makes it very hard to test and reuse. On the other hand, if your logic is nicely separated, you can test it easily and reuse it easily. Ideally, business logic should be completly independent on web environment.

Upvotes: 1

Related Questions