How do server controls violate MVC design pattern?

views:

answers:

+5 Q:

How do server controls violate MVC design pattern?

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.

+1 A:

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.

eglasius 2010-09-12 15:28:14

@eglasius: IMHO what you're describing is server control's lack of statelessness and simplicity, I can't see how these contradict MVC.

Oren A 2010-09-12 16:26:49

@Oren consider MVP (model view presenter) into the mix. One important difference between that and MVC is the handling of state, since MVP works with a view that changes based on the user actions / so regardless of where you put the state, the view isn't something that's showed just once. In MVC you show a different view on each action (yes, you could be showing the same file/view, but conceptually), the next action is handled unrelated from the previous. With asp.net classic+server controls, something that's common is show the same, but in this control show this data / or hide this.

eglasius 2010-09-13 15:38:28

Note that @tvanfosson might have something in mind regarding the responsibilities of the views vs. responsibilities of the controller, so he may have a more direct explanation based on whats (not) supposed to be on the views. For me I find it clearer with the MVP comparison, since you can have a nicely structured classic asp.net app with it, but still reveals an important difference with MVC. I think the MVC way is more aligned to the nature of HTTP. ps. note that asp.net MVC uses a variation of MVC, there are other variations.

eglasius 2010-09-13 15:50:27

Found the answer on "Pro ASP.NET MVC 2 Framework" by Steven Sanderson (page 5)

"...in reality developers are encourged to mix presentation code (e.g., manipulating the server-side control tree) with their application logic (e.g., manipulating database data) in these same monstrous code-behind classes.
Without better separation of concerns, the end result is often fragile and unintelligible."

Oren A 2010-09-15 20:54:22

ansaurus

tags:

views:

answers:

How do server controls violate MVC design pattern?

related questions