At the center of ASP.NET MVC is exactly what one would
expect. ASP.NET MVC is really just built on ASP.NET Forms and that really just
exists to create HTML (in the general case). I like to point this out since it
helps to limit a lot of the confusion that people often have when working with
ASP.NET, but this was mostly a problem with ASP.NET Forms. With MVC, a lot less
is abstracted and hidden away, so the process becomes far clearer.
With forms there were false layers of state which were
created and this makes a somewhat easier, although more dangerous, transition
for developers with backgrounds programming with state. This actually includes most developers, because most learn to write code on client machines. On these client machines there is usually maintained state to work with, so when you transition to the stateless architecture of web development, you expect state to be there. ASP.NET was designed with a false sense of state which makes that transition easier, and it makes a lot of logic seem far simpler. With MVC a lot more control is given to the
developer, but at the same time a lot of things are wired up already. By wiring a lot of things up automatically and still giving developers seams to make changes, the development is customizable and is still easy once you learn to use it.
This article is based on part of a lesson I created for a
group of junior developers who know a little bit of ASP.NET and C# and have a
basic understanding of the concept of the MVC pattern. In the article I cover
some of the basics of working with the data obtained from forms and form
controls on ASP.NET MVC pages. I discuss how to put that data into the view, as
well as different ways of accessing that data in the controller. The focus of
this article is not on testing or how best to work with that data once it has
been obtained. The focus is on the ways in which developers can get the data
using standard ASP.NET MVC methods.