None of that code belongs in the controller. Your 'typical' controller is anything but. All that code belongs in the model.
Your controllers should have zero LINQ statement. You should do all of the validation in the model and the validation failures should returned in a List.
This stuff's been in MVC for years:
http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mv...
When people talk about 'light' or 'skinny' controllers, this is what they're talking about.
So we're not doing MVC wrong, you've just developed bad habits from bad microsoft examples, work with some experienced Devs so they can teach you how to do it correctly.
That said, your points are good, and I agree, based on what I have learned myself to this point.
:-)
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?
Controllers should do only basic validation (length, format, etc.)
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.
The right way is the way that works for you and your business requirements.
All too often in my experience I see code that has the model rolled into the controller. Controllers and UI are structurally supported better in frameworks. We get lazy and put model code into controllers. It is the way we make spaghetti code today.
Ioc containers changed the way I code since I did not have to care anymore about how complicated it was to instanciate objects. It helps write very clean code and makes OOP easier.
I agree that the interactors make rather odd-looking OO classes, but I suppose the imperative nature of most requests to perform some logic make them less objects in that sense. This has the added benefit of seeing what the system does, just by looking the class names in the interactors folder/namespace.
Sounds similar to my understanding of what a monad is. If you have many cases of this, it might simplify the switch statement and improve maintainability.
http://devtalk.net/csharp/chained-null-checks-and-the-maybe-...
http://stackoverflow.com/questions/674855/help-a-c-sharp-dev...
Could you recommend any references for back-end patterns?
I agree.
> What is the responsibility of the controller?
Controllers are the UI ? but the UI of what ? HTTP. controllers should only deal with HTTP (request,respone,cookies,session) stuff , nothing else. The rest should be encapsulated in services, which communicates through models.
The truth is , it is not MVC , MVC is a poor label for that kind of architecture since MVC means something very specific in software engineering.
The approach I described above has nothing to do with CQRS, in fact it directly contradicts CQRS. The design of features is intended to combine commands and queries. If the controller is restricted to commands and queries then the logic of combining those operations ends up in the controller which is exactly what we need to avoid.
