ASP.Net MVC - What replaces events to support loose coupling?

Question

What feature(s) of ASP.Net MVC can replace the way events can be used in Webforms to support loosely coupled components?

For example, take a simple pager control in Webforms:

1. A page number is clicked
2. Pager fires off a "PageChange" event with the new page number
3. This subscribing page/control received the event and handles initiating a call to fetch and bind new data.

What tools are available in ASP.Net MVC to similarly support

• Loose coupling
• Component re-usability
• Separation of logic for a single page/view (such a very complex "portal" type page).

Answer 1

ASP.NET MVC, and the Model-View-Controller in general, support loose coupling and separation of concerns by keeping the data and code that supports an application separate from the visual "Presentation-layer" markup that is seen by users.

Designed properly, Controllers and Views in MVC can be reused so that the Edit View for an entity can be "embedded" into a related View with no modification.

For example: an Orders View might include an OrdersDetail partial view. That partial view could be replaced with the OrderDetail Edit View that is also available elsewhere within the application.

Separating the Model from the View makes unit testing more effective and less cumbersome by splitting the code from the context of the presentation layer. You don't want to have to reference System.Web to unit test code that fetches data from a database.

Answer 2

MVC does away with events because events for the most part are just an unnecessary layer between what the client is trying to tell the server to do and the server actually doing it.

In the paging example for webforms the client clicks the button, the browser sends the event/viewstate, and the engine fires the ButtonClicked event. You examine the event, determine the client is intending to page, and you execute the paging logic.

In the MVC paradigm the user clicks a button that makes a request directly to the code that executes the paging logic. Since you know what action the button is supposed to invoke when you put it there why go through all machinations of the event firing? In your controller you certainly could fire an event when you get the command but I honestly can't imagine the use case for doing so.

Both methods accomplish the same thing but MVC just removes a layer of complexity.