在我的代码中发现这一点后,我意识到了一些事情:
我实际上并不知道这与MVC3的关系
@model int
@using Company.Core.Logic.Financial
@using Company.Core.Repositories
@{
var values = from AccountPlan e in new AccountPlanRepository().GetItemList()
where String.IsNullOrEmpty(e.PromoCode) // filter out promotional plans
select new { id = e.AccountPlanId, name = e.Description };
var items = new SelectList(values, "id", "name", Model);
}
@Html.DropDownListFor(m => m, items)
这是一个特别是一个编辑器模板(@Html.EditorFor(m => m.AccountPlan)
),但它让我意识到我不知道这种代码在哪些方面适用于像菜单构建器这样的常见内容。如果您正在使用Layouts for MVC3(以及谁不是),那么基于用户角色在顶部构建菜单的代码在哪里?我认为视图代码将迭代预先构建的菜单项和HTML-ifying它们,但由于模型是强类型的,这是否意味着所有模型都需要了解菜单项?
有一次,这就是Webforms对我更有意义的地方,因为这会出现在CodeBehind中,但我真的想摆脱它。
编辑:即使我开始询问布局代码,我也认为它适用于EditorTemplates和DisplayTemplates。如果这是一个不正确的假设,请告诉我这些应该去哪里。
edit2:我最终想要的是拥有一个干净的,可能是依赖注入的地方来运行从EditorTemplate
调用的代码。也许这是EditorTemplate立即调用RenderAction的情况?
答案 0 :(得分:2)
看起来这很好地解决了问题(请参阅标记答案,而不是原始问题):
基本上,调用RenderAction(...)
它将构建所需的模型,而不是强迫您让每个模型都需要一个菜单项列表。
答案 1 :(得分:2)
就我个人而言,我基于活动目录组进行了大量的菜单过滤,因此我需要知道整个应用程序的访问级别。
我创建了一个名为ControllerBase的新控制器
public class ControllerBase : Controller
{
//authorization group setting an menu creation here.
//set properties and objects to ViewBag items to access from the front end.
protected override void Dispose(bool disposing)
{
_db.Dispose();
base.Dispose(disposing);
}
}
然后在我项目中的所有其他控制器上,我只是从ControllerBase扩展
public class HomeController : ControllerBase
{}
这会将我的所有服务器逻辑保存在一个文件中以管理权限,并在我需要根据权限隐藏或显示不同的ui元素时,让我的所有页面都能访问这些变量。
答案 2 :(得分:1)
您不应该(必须)访问View中的Repository。这属于控制器。
菜单在主页面中实现,您没有提供有关细节的详细信息。
答案 3 :(得分:1)
子动作非常适合这种情况。生成视图所需的逻辑包含在控制器操作中,就像正常情况一样,想要使用子操作的视图只是呈现操作..
你也可以缓存这些部分视图,这对于像主菜单这样的东西是有意义的 - 因为可能用户权限不会经常改变。
e.g。
[OutputCache(Duration = 300)]
[ChildActionOnly]
public ViewResult MainMenu()
{
var model = GetMenuModel();
return View(model);
}
想要呈现子动作的视图就是这样。
@{ Html.RenderAction("MainMenu", "Account"); }
因此,调用ChildAction的视图无需知道视图所需的模型。
如果您的子操作要求您将参数传递给它,RenderAction上也会出现重载。