views:

54

answers:

1

I'm currently working with ASP.NET and about to start learning ASP.NET MVC (2).
So before I open the first thick book and go through the first lengthy tutorial, what are the most important (new) concepts to keep in mind? What are the main new features I should be aware of?

Thanks a lot.

+4  A: 

No viewstate. No server-side controls. Think RESTful/stateless; it's a request/response cycle, not an event being handled.

It's worth consideration to take a side trip into Ruby/Rails to learn the concepts completely outside the .NET stack before you tackle MVC. I know that I was able to pick it up pretty quickly because I had already dabbled in Ruby/Rails enough to be familiar with the paradigm.

EDIT: I would also add that I find that separating view models from business models (entities) is a good idea. You should definitely be using strongly-typed views and passing models around rather than passing "untyped" ViewData to your views and pulling "untyped" data from the request or value providers directly. Using models and making the model-binding framework work for you will make it much easier both to test and keep your views cleaner. Using strongly-typed data in your views will at least give you some compile-time checking there as well.

tvanfosson
Woooooooow... (-: A little more info could be useful, though (-:
Oren A
@Oren - you asked for key concepts, not a detailed tutorial. I assumed that you know that it's MVC (Model-View-Controller) so haven't touched on that pattern (wikipedia has a good article on it). I just listed the main "gotchas" as I see it from a thinking perspective. You have to wrap your head around the fact that you don't get "events" like you do in WebForms and you don't have a magic container for your state. The lack of server-side controls is due to the inherent separation of concerns that makes MVC a good development pattern (and much more testable).
tvanfosson
Thanks. Great answer (-:
Oren A
@Oren - I've added a bit of advice on what I recommend for passing data to and receiving data from your views. Hope it helps.
tvanfosson
I realize "separating view models from business models (entities) is a good idea" (which I believe is a part of the MVC design pattern). But the terms "strongly-typed views", "value providers" and the main idea of your edited new paragraph goes way over my head.. (at least for now.. I'm guessing you're talking about the actual implementation of the MVC design pattern in code?!)
Oren A
@Oren - ASP.NET MVC has two ways of passing data into the view (server-side, let's not get into AJAX) - a ViewDataDictionary and the Model property on the ViewDataDictionary. You can make your view take a strongly-typed model (model of a particular class) or a generic (Object) model. Strongly-typed is the way to go. It lets you refer to your model's properties directly without casting to it first. The ValueProvider is how the framework gets data out of the Request. You can interface with it directly, but your model(s) as the action's parameter(s) is better...
tvanfosson
...the model binding framework will use the ValueProvider to "fill in" your model from the Request's parameters, taking care of any conversions for you. Quick note: value types often have to be nullable so you don't get a default when the parameter is not supplied with the request. The main idea is to leverage the strong-typing available in C# even in the views and the model binding framework to make passing data more object-oriented.
tvanfosson
Ok..Thanks for giving me a good starting point. Will take it from here (-:
Oren A
Hi again (-: I asked a question about your answer here: http://stackoverflow.com/questions/3695232/how-do-server-controls-violate-mvc-design-pattern. If you're willing to explain what you meant, that would be great. Thanks.
Oren A