Durante l'apprendimento di Sitecore, ho scoperto che la maggior parte del codice di esempio Sitecore sul Web si trova in XSL anziché in .NET.Quali sono i vantaggi dell'utilizzo di XSL in Sitecore anziché in C#?
Quale sarebbe il vantaggio di scegliere XSL sui processi a cui sono abituato come sviluppatore .NET?
Ci sono vantaggi di velocità di elaborazione nell'utilizzo di XSL?
XSL è effettivamente più semplice una volta che hai dimestichezza con la sintassi?
mi limiterò a aggiungere i miei 2 centesimi troppo:
trovo che ci siano troppo molte limitazioni in XSLT che devono essere superate con "librerie" esterne o con lo sviluppo di un metodo in C# che può essere utilizzato in XSLT.
Quindi trovo più semplice l'uso di Asp.Net. Ma poi sono molto meglio con Asp.Net che con XSLT.
Ma XSLT ha alcune cose buone:
Quando ho iniziato a lavorare con Sitecore, la mia azienda usato un po 'di XSLT, ma abbiamo lentamente andato via da quella, a causa della sua limitazioni e perché la maggior parte delle persone qui ha più familiarità con Asp.Net/C#.
Alcuni preferiscono l'XSL a causa del set di competenze del team esistente, la disponibilità del talento XSL o la convinzione che XSL sia più facile o meno costoso da apprendere.
In Sitecore, i sottofamiliari basati su ASP.NET offrono prestazioni migliori rispetto ai rendering XSL. Se è quello con cui ti trovi bene, fallo. Non ho mai creato personalmente un rendering XSL.
XSLT è un linguaggio potente; i suoi principali vantaggi rispetto a linguaggi come ASP.NET tendono a venire quando si desidera riutilizzare e personalizzare la logica su un'ampia varietà di pagine diverse o strutture di documenti di origine diversi con elementi condivisi comuni e altre strutture variabili. Per raggiungere questo obiettivo utilizza un modello di elaborazione basato su regole che alcune persone trovano abbastanza difficile affrontare al primo incontro. Imparare è un investimento che si ripaga nel tempo, ma all'inizio può essere scoraggiante.
Per quanto riguarda le prestazioni, non ho mai incontrato un sito in cui non è abbastanza veloce per il lavoro, e questo include alcuni servizi piuttosto stressanti; quando le persone hanno avuto problemi di prestazioni, di solito si sono rivelate in altre parti della pipeline di elaborazione (o semplicemente a causa di una cattiva programmazione).
Con specifico riferimento a Sitecore, tuttavia, XSLT presenta degli svantaggi in termini di prestazioni in alcune situazioni a causa dell'implementazione di Sitecore. La struttura XML è altamente generica, il che significa testare i valori del nodo piuttosto che i nomi. Anche la profondità del nodo è un possibile problema, rendendo costose le ricerche ricorsive. Non c'è scelta di processore nell'implementazione Sitecore, anche se probabilmente non sarebbe poi così difficile personalizzarlo. Infine, si basa anche su alcune estensioni XSLT in C#, che possono avere i propri svantaggi. –
Continua ... Da quello che ho visto su Sitecore, .NET è in genere il modo più efficiente di aggiungere componenti di presentazione che fanno qualcosa di più delle semplici attività di base. Esistono anche alcune best practice XSLT di Sitecore (come l'uso di Per ciascuna) che sono contro-intuitive per la maggior parte degli sviluppatori XSLT. –
La scelta tra XSLT e componenti .Net in Sitecore è in gran parte di gusto e competenze. XSLT in Sitecore ha però alcuni inconvenienti: tende a essere sovraperformato dai componenti .NET per tutti tranne i più semplici rendering e le aree in cui potrebbe sembrare più logico utilizzarlo, come la replica della struttura ad albero del contenuto come un menu del sito, sono in realtà quelli che tendono a prendere il più grande successo in termini di prestazioni. Nelle giuste situazioni XSLT è uno strumento incredibilmente potente e vale la pena imparare, ma non ho ancora visto un argomento convincente per farne un uso considerevole in Sitecore. Vale anche la pena notare che alcuni dei modelli standard di programmazione XSLT non sono i più efficienti in Sitecore.
L'unico vero vantaggio che posso pensare è che i rendering XSLT sono più facili da implementare separatamente. Supponiamo, ad esempio, che tu stia aggiornando il tuo rendering di "News Spots" e desideri distribuire subito questa modifica a test/produzione: sarebbe un semplice caso di caricare il file .xsl stesso.
Utilizzo dello sviluppo .NET (e la durata del modello di progetto di applicazione Web), una distribuzione della base di codice implicherebbe implicitamente qualsiasi modifica a tutti gli assembly interessati, incluso qualsiasi lavoro in corso.
Ci sono, naturalmente, modi per gestirlo. Il branching del codice sorgente/fusione e così via - ma questo è un ulteriore livello di complessità per la vostra soluzione.
Detto questo, io uso .NET per oltre il 95% di tutto il mio sviluppo Sitecore me :-)
"In breve, un obiettivo primario della progettazione e della codifica del software sta conquistando la complessità.La motivazione dietro molte pratiche di programmazione è ridurre la complessità di un programma.Ridurre la complessità è la chiave per essere un programmatore efficace." -Steve McConnell (1993)
Lasciamo questa guida quando usare XSLT su C#.
Senza caso d'uso, questo tipo di domande ("adventages di X anziché Y") sono soggettive e argomentative –
@Alejandro Sono d'accordo ora che lo sto guardando di nuovo. Qualche idea su come modificare la domanda? In caso contrario, ho intenzione di accettare la risposta di @James Walford – JoshBaltzell