2

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
  • stackoverflow.com/questions/27543211/…
    – gnat
    Commented Mar 4, 2015 at 8:41
  • 2
    @gnat I was suggested to put this question here instead. I deleted the other one.
    – tyftler
    Commented Mar 4, 2015 at 8:51
  • Why would you no longer need the data after the redirect?
    – JDT
    Commented Mar 9, 2015 at 13:01
  • @JDT Because the redirect (P/R/G) is exiting the script and demanding a new request.
    – tyftler
    Commented Mar 10, 2015 at 12:50
  • why do you need two model to handle the P/R/G cycle?
    – akr
    Commented May 8, 2015 at 18:27

2 Answers 2

1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.