Mikel
转载：http://blog.wekeroad.com/2008/01/07/aspnet-mvc-using-usercontrols-usefully/
This is an interesting issue, and as he went on to point out, there are lots of ways to use these partial UI bits to your advantage. As always, I'll offer some ideas here for you, but this is not the only way to do it.
The "Viewlet"
Given that a ViewPage inherits from System.Web.Page, you can still register and reference a UserControl (.ascx file) on a View and have it render. You can even pass it data in the code behind or as a property setting:
<uc1:MyUserControl ID=myControlView runat=server myProperty="Hi Mom" />
But using the WebForms model inside MVC can be a little confusing – especially for folks who will pick up your project later. In this case – the ViewUserControl will render just fine, and in many cases it's all you need. But if you're interesting in keeping things as modular as possible within MVC, read on.
Your UseControl can be one of two things:
- A granular bit of UI that renders information passed from a Controller
- A granular bit of UI that renders information from an application-wide data source
The idea here is reusability and maintainability.
I personally don't like the idea of putting logic into ViewUserControls, but at the same time it can serve a purpose – with portal stats for instance where you might want to serve up personalized links (using the Memebership.Profile for instance), etc.
In other MVC frameworks they make a distinction between the two. In Rails, for instance, a "Partial" is simply a View that's shared between views, and not meant to be standalone. If you've ever used Rails to create the demo scaffold, you've used the partial "_form.rhtml" which is responsible for rendering an input form for the New and Edit views.
If you need more than basic rendering of HTML in Rails, you can move to a Layout. Layouts essentially wrap UI around some logic, and are a nice modular way to reuse UI/logic elements around an application. These are like "UserControls Light".
Rails also allows for "sub apps" called "Components", which are useful when you have "sub applications" like an image gallery or rss reader. The idea here is that these components contain their own logic and can be used between many applications.
My point with all this is that if you feel lost trying to make a decision (architecturally) regarding MVC – it helps to see how other platforms do it (like Rails or Django).
Rendering a ViewUserControl
The MVC Toolkit has a nice method called "RenderUserControl()" that allows you to process your ViewUserControl and output it's result inline:
<%=Html.RenderUserControl(“~/UserControls/UserList.ascx”)%>
If the ViewUserControl is typed (say ViewUserControl<MyControllerData>), then it's ViewData object will be filled for you, and your ViewPage and rendered control will share the same data.
If you want to be explicit about it, you can do that as well, specifying the data to pass:
<%=Html.RenderUserControl(“~/UserControls/UserList.ascx”,ViewData.Users)%>
Finally, if you need to set properties on the ViewUserControl, you can do that as well by passing in an anonymous type:
<%=Html.RenderUserControl(“~/UserControls/UserList.ascx”,ViewData.Users, new {GroupID=2})%>
Using the RenderUserControl method allows you to have complete control over how your ViewUserControl is supposed to be used
Summary
UserControls are a great way (still) to encapsulate UI elements for your MVC app. There are many ways to use them, and if you have one I didn't mention (or dislike my approach here) – do let me know. As always – we're still CTP and there's lots of room for comments.
