views:

228

answers:

4

We are planning to use ASP.NET MVC on a relatively important (to the business) project. The development team comprises 4 developers and a Technical Lead. 2 of the devs and the Tech Lead have worked together before on ASP.NET WebForms project and are confident using that technology.

We cringe a little when we look back at some of the approaches used on some of our first WebForms project (examples include excessive use of UpdatePanels, lack of knowledge of controls such as the ListView, bloated ViewState etc).

It is important that we do not look back on this project in a year and cringe at some of our ASP.NET MVC approaches!

Based on experience, does anyone have any key risks they can cite when using ASP.NET MVC for the first time?

I am thinking about gotchas, lightbulbs that took a while to go on, parts of the framework that you felt you were fighting until you learnt a specific item, that sort of thing.

A: 

The biggest ones for me were understanding Model Binding and that you can have typed views.

Also properly securing your routes.

nikmd23
Can you add more detail? Model Binding - you're talking about strongly typed views? What do you mean about securing your routes?
Richard Ev
+6  A: 

Use Strongly Typed Views and create a new Model for each view

Simple reason: That is to make sure your Model is separted from your View. If you need to do refactoring, you only break one part. So if you have a View called "Latest News", you should have a "LatestNewsViewModel". It's then the job of the controller to get the data from the actual Model/Database and create a View Model that it passed into your views. Also, if you decide that you need additional stuff in your View, you don't have to refactor the entire Data Access Layer, as you only have to change the ViewModel and the Controller action that populates it.

Performance

I recommend checking out this slideshow about performance concerns and optimizations which can make a huge impact.

Michael Stum
Interesting slideshow in the link, thanks :)
Fredrik Mörk
I was under the impression that your models should not "care" about the views in which they are used (separation of concerns). Are you recommending two classes of models: those that represent "just" data, and those specifically tailored for use in views?
Richard Ev
Yes. Basically you have your usual Model classes to deal with reading and writing data to the database, but also you have separate Model classes for each view - so called View Models. Those View Models do not actually do anything, they are just a set of properties and hold exactly the data that the View needs. The Controller then talks with your "normal" model to get exactly the needed data, creates an Instance of the appropriate ViewModel and populates it and then sends it to the (strongly-typed) View. Seems overkill at first, but saves refactoring-headaches later on.
Michael Stum
Also see this link: http://www.mikesdotnetting.com/Article.aspx?ArticleID=105 where HomePageViewModel is the ViewModel in the example.
Michael Stum
+2  A: 

You can download a free eBook from Scotts Guthrie's blog take gives you a full in-depth guide on how to build an ASP.NET MVC site from scratch.

Michael Kniskern
+2  A: 

The biggest risks that I've seen come from a return to a stateless medium.

Postback is gone. Most server controls are gone. Viewstate is gone. Event driven model is gone.

If your devs have ONLY used asp.net webforms to build sites, and never another web technology, they are in for a lot of learning.

Chad Ruppert
I agree that it could be a lot of learning, but it's good learning ;-) Unforunately a lot web forms developers know very little about the web, in many cases less so than a typical classic ASP developer, who at least had to think abuot HTTP POST and GET even though most of the code ended up as spaghetti. I believe it's healthy for web forms guys to learn about MVC as it means they will learn what really happens in a web app. I disagree that it is a _return_ to a stateless medium. The web has always been a stateless medium, it's just that web forms hides the fact in a rather clumsy manner.
AdamRalph
Oh, totally. It is very good learning, and something that is very beneficial for any developer, if nothing more than it really show them how to use the nuts and bolts of HTTP. When I say return, for too many webforms folks, it *is* stateful. Viewstate is clumsy and ugly to those in the know, but to too many asp.net developers its the way the web 'works'.
Chad Ruppert