База данных контекста стекла null

Question

У меня возникла проблема с Glass Mapper в моем текущем проекте, с которым я не сталкивался раньше.
Непосредственно после того, как Sitecore был инициализирован, свойство Database в моем GlassContext (ISitecoreContext) равно null.

// 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 (Виндзор, поэтому по умолчанию Glass') для экземпляра, он возвращает мне один с действительным свойством базы данных.
В настоящее время я делаю эту проверку до получения каких-либо предметов, и ей нужна эта проверка только один раз (после этого это хорошо до следующей инициализации), но очень хотелось бы знать, что вызывает это.

Наверное, интересно знать: все запросы предметов (получение предметов, предметов литья и т. Д.) Выполняются через одну службу, которая получает в своем конструкторе ISitecoreContext.
ItemService имеет образ жизни Singleton, то ISitecoreContext имеет образ жизни Transient

Answer 1

Я думаю, что ваш NewsService был первый раз вводил перед тем Sitecore имеет действительный контекст, для этого стекло также не может быть действительным контекст (базы данных). Потому что у вашего ItemService есть Singleton lifetime, конструктор вызывается только один раз, а разрешение ISitecoreContext выполняется один раз. Это означает, что если ваш ItemService разрешен в первый раз, когда Sitecore имеет действительный контекст, то ваш glassContext будет null. После того, как вы вручную установили свойство glassContext в экземпляре Singleton, в следующий раз он будет недействительным (но может быть недействительным, поскольку вы находитесь в другом запросе).

Я предлагаю вам установить обе зависимости либо на Transient, либо на PerWebRequest.

Answer 2

Как указано в других комментариях, иногда это связано с тем, что не указывается соответствующий образ жизни. Transient может дать вам утечку памяти, если вы не нашли подходящего способа ее выпуска. Я лично часто использую NoTrackLifestyle, который поставляется с Glass Mapper, поскольку он ведет себя как Transient из других контейнеров.

Есть также случаи, когда вы можете попытаться разрешить службу слишком рано, это особенно может случиться при запуске в записях конвейера и т. Д., Где контекст еще не разрешен для запроса. В этих случаях вы можете использовать либо именованный экземпляр, где вы указываете базу данных и/или ее имя, как зависимость.

Помните, что во всех случаях контекст/служба sitecore по умолчанию зависит от базы данных CONTEXT, если Sitecore еще не разрешил ее - ни у нее не будет стекла.

При использовании его с новой функциональностью Glass Delegate я считаю необходимым иногда полагаться на заводскую реализацию, которая задерживает получение услуги, она не идеальна, но служит ее целям, поскольку плавная конфигурация часто не будет имеют контекст, доступный во время создания экземпляра. Добавив небольшую фабрику, она может быть отложена до тех пор, пока фактически не будет делегированный код.

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

Иногда также возникают случаи, когда Glass используется при создании диалоговых окон SPEAK/Sheer UI.