有人知道为什么 BlockData 类不直接实现 IContent 吗?我知道在从数据库中检索 BlockData 期间,Castle 创建的代理实现了 IContent。
如果 StackOverflow 不适合此类问题,请移步。
有人知道为什么 BlockData 类不直接实现 IContent 吗?我知道在从数据库中检索 BlockData 期间,Castle 创建的代理实现了 IContent。
如果 StackOverflow 不适合此类问题,请移步。
EPiServer 的 Johan Björnfot 在这篇文章中解释了一些细节。
摘抄:
“在以前版本的 CMS 中,页面 (PageData) 是内容存储库(传统上是 DataFactory)处理的唯一内容类型。在 CMS7 中,这已经改变,所以现在内容存储库 (IContentRepository) 处理 IContent 实例。这意味着对 .NET 的要求可以从内容存储库保存/加载的类型是它实现了接口 EPiServer.Core.IContent。
CMS 中内置了一些 IContent 实现,例如 PageData 和 ContentFolder(用于对共享块实例进行分组),并且还可以注册自定义 IContent 实现。如果您查看 BlockData,虽然您会注意到它没有实现 IContent,如何那么共享块实例是否被处理?
答案是,在运行时创建共享块实例时(例如,通过调用 IContentRepository.GetDefault,其中 T 是从 BlockData 继承的类型),CMS 将使用称为 mixin 的技术创建一个继承 T 的新 .NET 类型,其中新的生成的子类将实现一些额外的接口(包括 IContent)。”
BlockData 确实实现了 IContent,因为它既可以在添加到另一个内容项(例如 PageData 实例(又名本地块))时工作,也可以作为独立实例(又名共享块)工作。在后一种情况下,通过使用Castle Windsor 的混合来添加接口,以便可以引用它。
这个结构的决定是基于希望能够使用相同的渲染模板,无论一个块是本地的还是共享的。因此,选择是在本地块上拥有大量空属性还是使用 mixin 的当前解决方案。这两个选项都经过了测试,并且选择了 mixins 作为首选解决方案,即使它不是一个完美的解决方案。
BlockData“确实实现了 IContent”,只需执行以下操作:
var myContent = (IContent)myBlock;
但是,如果您有机会处理本身是属性(而不是 ContentReference)的 Block,则该强制转换将引发异常。
这对于 100% 的所有情况都是正确的(...使用 Math.Round)。