[r0s]

What's the advantage?

Is the model constantly pulling session state to validate against?

Does this prevent caching of data on the models? Or is there 'supposed' to be some even higher level API manager that deals with the responses before they get to the model?

[pionar]

Your controller should be passing the session state to the model (passing the items needed from session state for the model to manipulate data). Models should have no concept of a session. They should be almost entirely self-contained.

Controllers should do only basic validation (length, format, etc.)

[mattmanser]

It sounds like you're stuck using `Session` object which you should almost never touch in ASP.Net MVC.

HTTP is stateless. You should program accordingly and not rely on the old ASP.Net webforms ways, they were extremely broken and taught some developers some very bad habits (view state was a terrible, terrible idea. Session state should be used in extremely rare circumstances and it's much better to never use it).

That's one of the reasons MVC caught on so fast. It actually reflects what in reality is happening and is not the terribly leaky abstraction that Webforms was.

In the controller you get an updated object from your repository on each request. You update it with the data that you received in the request (and MVC can do this for you itself). You ask it to validate itself. You save if valid. You return your success view. You don't save if not valid, you return the validation errors.

Hence the controller is only a few lines.

That's how you're supposed to program in MVC because HTTP is stateless. And because SQL is much faster than you probably think it is. And that makes the code vastly simpler. And you can cache persistent things like the data for common dropdowns in memory using the actual `System.Runtime.Caching` functionality.