I have a question in mind for the MVC pattern for a long time now. When using the Post/Redirect/Get principle then it doesn’t make sense to use ONE model in the sense of MVC, right? Why should I modify the data in the model if I don’t use it anymore? Am I missing something?
So I need one model for the actions in the controller and one with the data for the view?
My current pattern:
controller
-> call and init model used for actions
-> handle actions using the action model, if an action has been executed, use P/R/G to reload
-> call and init model used for the view
-> call view with template and pass view model
The point is, I don’t want to load all the data for the view if I possibly don’t need it due to the redirect. Or am I just caring about that too much?
6
In MVC it’s very uncommon to have a single model or controller. It is however common to have one or very few view “flavors” which all render templates differently.
Each controller should have a single purpose, whether it’s routing, or applying business logic to a model. You should route the request to the appropriate controller for each model, ideally separating POST and GET handling into separate functions. If POST, save and redirect. If GET, display the view.
- Model = Structured data. Throws validation exceptions. May contain storage logic.
- Controller = Routing and business logic. Works on models directly or through another controller. Assigns presentation data to views, such as models, headers, sub-views, etc. Dies gracefully upon errors.
- View = Presentation. Uses whatever it’s given in a read-only way. Should produce no errors.
If you’re asking whether it’s correct to initialize the model for each type of request, the answer is probably yes, unless your POST validation is incredibly simple and is allowed to clobber existing records.
All the data in your view is from the last GET, it has already been loaded, processed, and forgotten. The POST action is just updating some of it. What is reloaded during the POST just depends on the model and how it is used.
The reason for the Post/Redirect/Get approach in my experience is to prevent the common issue of re-posting data when using the “back” and “forward” buttons in a browser. The redirects happen server side and the browser just tosses out the POST from its history. This also keeps the user from bookmarking the POST URL because it is displaying the GET view they want to reference later.
Once that redirect happens, any state you had in the POST action is lost, this includes any models that was called up. However, it could also be that the POST action model didn’t have all the data loaded anyways (such as updating an order address), therefore the GET would have to enrich it with another model (such as the line items in an order).
This assumes that you are not doing a lot of AJAX and/or client side dynamic stuff here. That each view is all the data retrieved in one request.