What place for server controls in ASP.Net MVC?

Question

Hello. What is the recommended replacement of ASP.Net server controls in the bright new world of ASP.Net MVC?

In my opinion, one of the best features of ASP.Net is the ability to write server controls (although, admittedly, the event model is horrendous to deal with). If these controls are self-populating, then they can be shared between different projects with the minimum of fuss - you simply reference the assembly where the server control lives, and drop it on to the aspx. The control does the rest. This fits very nicely in the World of Widgets and provides efficient code reuse. How is one meant to achieve the same thing in MVC?

I am most interested in self-populating controls that do not post back, as I appreciate that the postback model definitely does not fit with MVC. Can they still be encapsulated in a class that can be shared between a number of different MVC web projects? Or does this require a whole different mindset where controls shouldn't populate themselves, and one should use partial views? Is there a way of sharing partial views between projects?

Finally, can I use my old (non-postback) server controls, in an MVC projects?

Answer 1

You can mimic the behavior of non-post back controls with Html helper extension methods. Just like Html.TextBox(), etc, you can write your own and encapsulate them in their own project if you like.

If you've written controls that just output HTML, it shouldn't be that hard to convert them to Html helpers.

Answer 2

The closest Asp.Net MVC comes to server controls is partial requests. In a partial request an MVC action method is called, and its output is appended to the current view. Unfortunately, the official support for this (Html.RenderAction) is in the futures assembly at the moment.

If using the futures assembly is not possible for you, a blogger named Steve Sanderson has written an article on implementing similar functionality:
http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/