Sitecore Glass Mapper: Атрибуты на интерфейсах или конкретные классы?

Question

Мы новичок в Glass Mapper и хотели использовать его в нашем проекте Sitecore. Когда мы смотрели на уроки, мы заметили, что не было никаких глубоких примеров того, как настроить глубокое наследование, которое позволяет Sitecore. При просмотре веб-страниц мы заметили, что есть люди, которые работают с размещением атрибутов на интерфейсах, а с другой стороны - люди помещают атрибуты в конкретные классы. Ни один из этих примеров не объясняет их веские причины для этого, однако оставляя нам вопрос: , который является правильным использованием и каково влияние того или иного?

Рассмотрим следующий пример:

Шаблон: Материалы (который является шаблон раздела поле добавления 2 простых полей: заголовок, тело) Этот шаблон прямо или косвенно унаследованы многие из наших шаблонов.

Теперь в одном из наших подслоев мы используем только этот раздел, и это своего рода более общий контроль, поэтому нам нужно сделать: GetCurrentItem<Content> или GetCurrentItem<IContent>.

Лично я считаю, что GetCurrentItem<IContent> более интуитивно понятен, так как он чувствует, что спрашивает: «Дайте мне текущий элемент, если он поддерживает раздел содержания», где другой больше напоминает «Дайте мне текущий элемент, если он является секцией контента» (что технически невозможно, поскольку элементы контента никогда не создаются)

Answer 1

Конфигурирование интерфейса для Glass Mapper может служить целым рядом целей. Во-первых, Glass Mapper может фактически создавать динамические прокси-объекты на основе вашего интерфейса. Это означает, что вы можете использовать Glass Mapper только на основе интерфейса, без вашей собственной конкретной реализации.

Mike Edwards describes this here.

За кулисами Glass.Sitecore.Mapper картографа обнаруживает, что вы с помощью интерфейса и использует замок Dynamic Proxies для создания конкретного класса, что ваше приложение может использовать.

Как он указывает, это добавляет некоторые накладные расходы и делает невозможным добавление дополнительной логики.

The other use is type inference. Это плохо документировано в контексте интерфейсов, но при вызове SitecoreService или в ваших атрибутах поля попросите Glass Mapper вывести типы. Для этого поведения вам не нужно отображать поля интерфейса.Обязательно укажите TemplateId в атрибуте SitecoreClass вашего конкретного класса. Это должно позволить вам моделировать множественное наследование.

public interface ISitecoreItem { 

    Guid ID{ get; } 

    Language Language{ get; } 

    int Version { get; } 

    string Url { get; } 
} 

[SitecoreClass] 
public partial interface IHeader : MyProject.Content.ISitecoreItem 
{ 

    Link LogoLink {get; set;} 

    Image Logo {get; set;} 

} 



    [SitecoreClass(TemplateId="87d5b6c1-a084-4738-be11-b4e6fe07d894")] 
    public partial class Header : IHeader 
    { 
     [SitecoreId] 
     public virtual Guid ID{ get; private set;} 

     [SitecoreInfo(SitecoreInfoType.Language)] 
     public virtual Language Language{ get; private set; } 

     [SitecoreInfo(SitecoreInfoType.Version)] 
     public virtual int Version { get; private set; } 

     [SitecoreInfo(SitecoreInfoType.Url)] 
     public virtual string Url { get; private set; } 

     [SitecoreField(FieldName = "Logo Link")] 
     public virtual Link LogoLink {get; set;} 

     [SitecoreField(FieldName = "Logo")] 
     public virtual Image Logo {get; set;} 


    } 

var service = new SitecoreService(Sitecore.Context.Database); 
var header = service.CreateClass<IHeader>(false /* don't lazy load */, true /* infer type */, headerItem); 

Answer 2

Я нахожу моделирование своих шаблонов Sitecore с использованием интерфейсов, как правило, лучшим вариантом. Это позволяет мне смоделировать структуру шаблонов в коде, как и в Sitecore. Например,

public interface IMyPageTemplate : IBaseTemplate1, IBaseTemplate2 { 

} 

Это гораздо более сложно смоделировать наши шаблоны с конкретными классами, так как мы обычно имеют ряд базовых шаблонов. Возможно, стоит подумать (хотя, я не пробовал) какую-то комбинацию интерфейсов и конкретных классов. Возможно, шаблоны, которые являются строго базовыми шаблонами, например IContent, должны быть смоделированы как интерфейсы и все шаблоны, которые могут быть созданы, поскольку контент должен быть смоделирован как конкретные классы.

Возможно сделать что-то наподобие GetCurrentItem<IContent>(). Стоит только отметить, что возвращаемый результат - это прокси-класс, который может обеспечить его собственные проблемы (в зависимости от того, что вы делаете).