我将 Umbraco 与 Razor 结合使用作为 CMS。这种方法的一个限制是我的页面模板绑定到一个不具有我需要的所有属性的 Umbraco 特定对象。到目前为止,为了解决这个问题,我已经多次调用以@Html.Action()
显示由我的控制器构造的部分视图。
这是实现我想要的一种昂贵的方式吗,还有其他方法可以绕过绑定到您无法控制的视图模型的限制吗?
我将 Umbraco 与 Razor 结合使用作为 CMS。这种方法的一个限制是我的页面模板绑定到一个不具有我需要的所有属性的 Umbraco 特定对象。到目前为止,为了解决这个问题,我已经多次调用以@Html.Action()
显示由我的控制器构造的部分视图。
这是实现我想要的一种昂贵的方式吗,还有其他方法可以绕过绑定到您无法控制的视图模型的限制吗?
当然,这个问题的答案是“视情况而定”。
每个人都@Html.Action()
对 a 上的操作发出独立的请求Controller
。显然,任何调用@Html.Action()
都会产生更多的开销而不是根本没有。
除此之外,在 Umbraco 中,假设您在SurfaceController
类上调用动作,Umbraco 引入了一个附加层,它使用上下文实例化控制器并连接动作。
但是,所有这些使用都@Html.Action()
允许您拆分视图模型并提供独立于页面模型的功能。这是回报,我认为这是足够的优势。这里重要的是确保您使用此技术足以使代码库易于管理,同时仍使请求高效。例如,不要使用它显示可以通过页面模型直接访问的内容。为此,您可以只使用部分。
您应该始终检查您的 ChildAction 代码,以确保尽可能使用缓存并适当地减少每次调用的处理量。例如,我总是使用 ChildAction 来生成我的主导航,但是由于 nav 永远不会更改,我缓存了返回的模型,因此对操作的调用尽可能快。
最后,如果您的控制器具有 EF 数据库上下文等依赖项,请使用 Autofac 等 IoC 容器来确保每个实例的依赖项被假脱机一次,然后共享。这确保了控制器(以及操作)使用的任何资源都是重复的。