ASP.NET MVC is a pretty nice framework. If you care about unit testing, convention over configuration in your ASP.NET applications, you might want to take a look at MVC. If you do Webforms, keep in mind though that many of the features available in MVC are also available in Webforms. Think about URL Routing for instance. I
Check the following points about ASP.NET MVC and also take a look at the video by clicking on the image.
– IHttpHandler is the atom of ASP.NET programming.
– Choose to go a bit further down. Everything you need is most of times found in analyzing the Call Stack.
– ActionInvoker and ModelBinding (using Routing) are also at the center of ASP.NET MVC.
– In ASP.NET MVC You can change the way controllers are invoked or models are bound, if you don’t like it.
– Routes happen in the order in which they are listed.
– You can create strongly typed views. For that, you can pass an instance of your model to your view.
Your view, then, in the markup should be configured to accept specific model class types, using System.Web.Mvc.ViewPage<T> where T is your model object type.
– You can also use ViewModels to create a bridge between your views and the associated model. MVC then becomes MV MV C.
– You can overload methods to differentiate between GET and POST requests. Use the HttpPost attribute to mark it so that it can only be called as a POST request.
– You can use Automapper, which is a tool, that uses reflexion to do mapping between your model objects and ViewModel entities.
– Keep in mind the View job is only and only to display stuff, not do calculations, or other logical stuff.
You can eventually add loop statements to display serie of items on your view.
– ViewData is like an hashtable where you can put stuff from your controller and retrieve it in your View using something like <% ViewData[“…”] %>
– View engines are the thing that generates the angle brackets. ASP.NET uses what we call the ‘WebForms view engine’.
The name is unfortunate because Webforms is not involved at all in this mechanism.
Controllers don’t know who called them. That’s what makes Testing work in MVC, because you can also call the controller.
At some point, you may need to new up your controller in your test class.
That’s where separation of concerns also becomes important. If your controller does something like ‘Response.Write’, that will work at runtime, but not in Testing.
However, it’s not the controller’s responsibility.
We don’t have any Response object or HttpContext.
Make sure your controller doesn’t touch things it’s not supposed to.
We switched, from early MVC versions to more recent ones, from something like
public void ActionName()
public ActionResult ActionName()
This changes enables us do all the testing we do. How could have we tested our actions if they were returning Void ?
How could have we doing Assert statement on the view ?
Be careful and avoid adding code-behind code to your Views.
You need to keep Separation of Concerns in mind every time, when you use ASP.NET MVC.
Convention over configuration: One big difference between Webforms and ASP.NET MVC.
Separation of concerns and single-responsibility principle are driving ASP.NET MVC.
Webforms value the Control function.
If you like the more productive but less detail oriented perspective then go with Webforms.
Webforms values Event abstraction, ecosystem of all the controls you can work with, Server side eventing.