Question

我在当前项目中遇到Glass Mapper的问题，我之前没遇到过。
在Sitecore初始化之后，我的GlassContext（Database）中的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＆＃39;默认）询问实例时，它会返回一个具有有效数据库属性的框架。暂时我在检索任何项目之前进行此检查，并且只需要一次这样的检查（之后它会很好，直到下一次初始化），但是真的想知道导致这个的原因是什么

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

Answer 1

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

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

Answer 2

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

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

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

当将它与新的Glass Delegate功能一起使用时，我发现有时必须依赖工厂实施来延迟服务的获取，这不是完美的，但是从那时起就是为了它的目的。流畅的配置通常在实例化时不具备上下文。通过添加一个小工厂，它可以被延迟，直到实际调用委托代码。

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

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

Glass上下文数据库null

2 个答案: