How do server controls violate MVC design pattern?

Question

The reason I'm asking is tvanfosson's (first) comment to his answer to another question of mine where he said (about ASP.NET MVC): "The lack of server-side controls is due to the inherent separation of concerns that makes MVC a good development pattern..".
I surely know ASP.NET server controls, and I think I know MVC design pattern, but I don't understand how server controls violate MVC.

Thanks.

Answer 1

I think it has a lot to do with the postback + viewstate + events model.

The above occurs implicitly to simulate a model where the user is interacting with the app in a multi-step way, where there are various states of the system. As each control holds its viewState, each inherently contributes to this overall state, which can become hard to follow as the page grows in complexity. I also believe that convenience encourages said complexity.

The above might be more of an argument to restful, which promotes relying more on the protocol's way of doing things. Using posts to achieve the above, is really not intended by the HTTP protocol. Just take original built-in paging of asp.net grids, as it was based on postbacks search engines ignored anything beyond page 1. Also you no longer had a way to access said page of info just by url.

imho the MVC pattern in the context of asp.net MVC is more about simple request/response operations. You can get it to be as complex as you may need, but it promotes a more simple operations way of doing things. Its not based on working with state based on several different bits of information scattered on the page/view as in classic; but if that's what you need you can still achieve it, but you'd have to be a lot more explicit when doing so.