Sitecore Glass Mapper: attributi su interfacce o classi concrete?

Question

Siamo nuovi in ​​Glass mapper e volevamo utilizzarlo nel nostro progetto Sitecore. Guardando le esercitazioni abbiamo notato che non c'erano esempi profondi su come impostare l'eredità profonda che consente Sitecore. Durante la navigazione sul Web abbiamo notato che ci sono persone che lavorano con il posizionamento degli attributi sulle interfacce e dall'altra parte ci sono persone che posizionano gli attributi sulle classi concrete. Nessuno di questi esempi spiega la loro buona ragione per farlo, ma ci lascia con la domanda: che è l'uso corretto e qual è l'impatto di fare uno o l'altro?

Si consideri il seguente:

Template: Content (che è un modello di sezione campo aggiungendo 2 campi semplice: titolo, il corpo) Questo modello è direttamente e indirettamente ereditato da molti dei nostri modelli.

Ora in uno dei nostri sublayout usiamo solo questa sezione ed è una specie di controllo più generale, quindi dobbiamo fare: GetCurrentItem<Content> o GetCurrentItem<IContent>.

Personalmente trovo il GetCurrentItem<IContent> più intuitivo in quanto mi sembra di chiedere: "Dammi l'elemento corrente se supporta la sezione del contenuto" dove l'altro sembra più "Dammi l'elemento corrente se si tratta di una sezione di contenuto" (che tecnicamente è impossibile dal momento che gli articoli del contenuto non vengono mai creati)

Answer 1

La configurazione di un'interfaccia per Glass Mapper può servire a un paio di scopi. Innanzitutto, Glass Mapper può effettivamente creare oggetti proxy dinamici basati sulla tua interfaccia. Ciò significa che è possibile utilizzare Glass Mapper basandosi esclusivamente su un'interfaccia, senza la propria implementazione concreta.

Mike Edwards describes this here.

Dietro le quinte Glass.Sitecore.Mapper mapper rileva che si sta utilizzando un'interfaccia e utilizza Castello proxy dinamici per generare una classe concreta che l'applicazione può utilizzare.

Come sottolinea, questo aggiunge un sovraccarico e rende impossibile aggiungere ulteriore logica.

The other use is type inference. Questo non è ben documentato nel contesto delle interfacce, ma nel chiamare SitecoreService o negli attributi del campo, chiedere a Glass Mapper di inferire i tipi. Per questo comportamento, non è necessario mappare i campi dell'interfaccia.Assicurati di includere lo TemplateId sull'attributo SitecoreClass della tua classe concreta. Ciò dovrebbe consentire di modellare l'ereditarietà multipla.

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

Trovo che la modellazione dei modelli di Sitecore con le interfacce, in genere, sia l'opzione migliore. Questo mi permette di modellare la mia struttura modello in codice molto simile a quella esistente in Sitecore. Ad esempio,

public interface IMyPageTemplate : IBaseTemplate1, IBaseTemplate2 { 

} 

È molto più difficile modellare i nostri modelli con classi concrete poiché generalmente abbiamo un numero di modelli di base. Forse vale la pena considerare (anche se non l'ho provato) una sorta di combinazione di interfacce e classi concrete. Forse i modelli che sono rigorosamente di base, come IContent, dovrebbero essere modellati come interfacce e tutti i modelli che possono essere creati in quanto il contenuto dovrebbe essere modellato come classi concrete.

È valido per fare qualcosa come GetCurrentItem<IContent>(). Vale la pena notare che ciò che viene restituito è una classe proxy che può fornire le proprie sfide (a seconda di ciò che si sta facendo).