我正在使用ASP.NET MVC将我的HTML视图与我的模型分开。然而,有一个特定的情况令我感到困惑。
我有几个常用的小面板信息,它们本身由一些较小的信息板组成。这些数据来自各种模型中包含的子类,有时是单个实例,有时是对象列表。
目前,这是使用部分视图完成的,通过模型参数传递适当的数据,如下:
@Html.Partial("UserInfo", this.Model.CurrentUser);
@Html.Partial("UserInfo", reply.PostedBy);
等等。一切正常。
我最近达到了一个要求,感觉它延伸了这个模型的明显限制 - 但它将涉及大量的局部视图,每个部分视图中有少量的HTML,嵌套了很多次。页面解析时间似乎开始有点失控,我怀疑搜索和反映部分视图的数量可能与它有关。
请注意:我假设重复的HTML应该是相同的仍然是要避免的。我可以通过在某些更高级别的控件中使用HTML副本来简化嵌套,但这会让我感到损害可维护性。
对于最内部的那些,我似乎更有意义创建生成并返回所需HTML的静态辅助类 - 但是,尽管事实上MVC本身使用Html
辅助类来实现它,感觉这违背了MVC模式。
UserInfo
课应该去哪里?看法?控制器?别处?显然,这种方法仍然将辅助方法与模型分开,但由于需要使用模型,我真的不知道它实际上是如何解耦的。
静态助手是一种远离扩展方法的头发宽度,可以userInstance.InfoHtml()
类型的方式使用,这似乎使整个方法非常类似于仅将辅助方法添加到模型中。这当然是MVC首先试图摆脱的目标!
请注意:我不是想绕过规则或抱怨!我只想尽可能地将其视为“on pattern”。如果有很多很多部分观点的话,我会尽我所能坚持这个和表演调。
答案 0 :(得分:4)
我相信有四种常见的解决方案可以在问题中重复使用html。
@Html.Partial
); @Html.Action
); @Html.Whatever
,@Url.Whatever
,模型的扩展方法等); @helper
)使用静态帮助程序类生成小的HTML代码段是否可以?
使用静态帮助程序类生成小的HTML代码段是否完全正常。我不喜欢将它们作为方法添加到模型中,扩展方法也可以。
我想说这些方法之间的差异主要在于编码风格和个人偏好。我会使用部分视图来打破耗材片段的大视图,应用程序的真正常见和独立部分的子操作(如小部件或登录框),所以我不必用我的所有视图模型填充常见事物的数据。对于非常小的html片段(表单中的字段),我会使用静态助手或剃须助手,其中包含更多代码的静态助手和更多html的剃刀助手。
静态UserInfo类应该去哪里?看法?控制器?别处?
这些东西属于从模式角度看的视图。如果您询问应该在解决方案中填充哪些文件夹,我会为它们推荐一个特殊文件夹(可能是HtmlHelpers
)。共享剃须刀帮助程序可能存在限制驻留在App_Code
文件夹中。
我认为以下问题将为您提供更多如何选择的方法:
新的ASP.NET MVC中可能有第五个解决方案:View Components。据我所知,你可以使用它们代替儿童行动。
答案 1 :(得分:1)
根据您在此处提供的内容,很难说出您的最佳途径。很大程度上取决于你正在做什么以及你想要达到的目标。
例如,您当前通过部分视图包含的用户信息,听起来就像是通过子操作更好地提供服务:
[Authorize]
public class AccountController : Controller
{
...
[ChildActionOnly]
[AllowAnonymous]
public ActionResult UserInfo()
{
// get your user info here
return PartialView("UserInfo", userInfo);
}
}
然后在你的视图/布局中:
@Html.Action("UserInfo", "Account")
然后,您无需确保在您正在使用的任何视图模型上填充用户对象。
接下来,像Html.Partial
等Razor助手方法本身只是HtmlHelper
或UrlHelper
助手的Url.*
扩展。添加自己的扩展方法没有错。例如,在将HtmlHelper
扩展到开箱即用的MVC 5之前,将EnumDropDownListFor
扩展为自定义{{1}}是很常见的。但是,扩展实际上最适合于一小部分HTML,这似乎是您想要使用的内容。对于大块的HTML,使用partials更有意义。但要么是有效的。在很大程度上取决于您只需确定最适合您应用的内容。