1

我在当前项目中遇到了以前从未遇到过的Glass Mapper问题。
在 Sitecore 初始化之后，Database我的 GlassContext ( ISitecoreContext) 中的属性立即为空。

// After Sitecore initialization, sometimes the glass context database is not initialized yet.
if (this.glassContext == null || this.glassContext.Database == null)
{
    this.glassContext = DependencyInjection.Container.Resolve<ISitecoreContext>();

    // Now I have a valid this.glassContext.Database ...
}

当我向我的 DI 框架（Windsor，所以 Glass 的默认值）询问一个实例时，它返回给我一个具有有效数据库属性的实例。
暂时我在检索任何项目之前做这个检查，它只需要这个检查一次（之后它很好，直到下一次初始化），但真的很想知道是什么导致了这个。

可能很有趣：所有的项目请求（获取项目、铸造项目等）都是通过一个服务完成的，该服务ISitecoreContext在其构造函数中初始化。
有ItemService生活方式Singleton ,ISitecoreContext有生活方式Transient

4

2 回答 2

2

我认为您NewsService是在 Sitecore 具有有效上下文之前首次注入的，因此 Glass 也不能具有有效的上下文（数据库）。因为你ItemService有一个Singleton生命周期，所以构造函数只被调用一次，并且解析也ISitecoreContext只完成一次。这意味着，如果ItemService在 Sitecore 具有有效上下文之前第一次解决了您的问题，那么您glassContext将是null. 在Singleton实例中手动设置glassContext属性后，下次它不会为空（但可能无效，因为您在另一个请求中）。

我建议您将两个依赖项都设置为Transient或PerWebRequest。

于 2014-12-22T13:13:25.320 回答
0

正如其他评论中所述，有时这是由于未指定适当的生活方式。如果您没有找到适当的方法来释放它，瞬态可能会给您带来内存泄漏。我个人经常使用 Glass Mapper 附带的 NoTrackLifestyle，因为它的行为更像是来自其他容器的 Transient。

在某些情况下，您可能会尝试过早地解析服务，尤其是在管道条目中运行时，如果上下文尚未为请求解析，则可能会发生这种情况。在这些实例中，您可以使用指定数据库和/或其名称作为依赖项的命名实例。

请记住，在所有情况下，sitecore 上下文/服务默认依赖于 CONTEXT 数据库，如果 Sitecore 尚未解决它 - glass 也不会。

将它与新的 Glass Delegate 功能一起使用时，我发现有时需要依赖延迟获取服务的工厂实现，它并不完美，但可以达到它的目的，因为流畅的配置通常没有可用的上下文在实例化的时候。通过添加一个小工厂，它可以延迟到实际调用委托代码。

public interface ISitecoreServiceFactory
{
    // Gets the Sitecore service from the container
    ISitecoreService GetService();
}

当 Glass 用于创建 SPEAK / Sheer UI 对话框时，有时也会出现这种情况。

于 2014-12-28T09:26:13.007 回答