Razor o XSLT sono migliori per il mio progetto? [chiuso]

I HANNO usato con successo XSLT come livello di presentazione web ... nel 1999. Negli ultimi 12 anni sono arrivate opzioni molto migliori. Fai un grande favore e usa Razor. È un piacere.

Ecco un confronto di sintassi di base          

Razor

@foreach(var item in View.List) {
  <span>@item.Name</span><br/>
}

XSLT          

  <xsl:template match="/">
    <xsl:apply-templates/>
  </xsl:template>

  <xsl:template match="item">
    <xsl:for-each select="name">
      <xsl:value-of select="."/><br/>
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>

Le origini dati per i due esempi

XML

<?xml version="1.0" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
<list>
    <item>
        <name>List item one</name>
        <url>http://site.com/one</url>
    </item>
    <item>
        <name>List item two</name>
        <url>http://site.com/two</url>
    </item>
</list>

C #

ViewModel.List = new[] {
    new Link {
        Name = "List item one",
        Url = "http://site.com/one"
    },
    new Link {
        Name = "List item two",
        Url = "http://site.com/two"
    }
};

Esiste una relazione 1: 1 tra pagine HTML e output XML? Prendi in considerazione i seguenti casi:

• strong correlazione: ogni pagina web ha un codice HTML e un modulo XML corrispondente.

Esempio: stai ospitando un sito Web con recensioni di film. Hai una home page con le ultime recensioni, una pagina per recensione e una pagina con commenti e valutazioni degli ospiti. Non c'è nessuna registrazione. Vuoi semplificare l'utilizzo del tuo sito web in modo programmatico senza la brutta analisi HTML. In questo caso, puoi avere una relazione 1: 1: tutto ciò che l'umano può fare, anche il bot può farlo: con le stesse richieste, otterrà lo stesso contenuto.

Il link è utilizzato dagli esseri umani.
link viene utilizzato dai bot per accedere alle stesse informazioni.

• Debole o nessuna correlazione: ci sono solo un sacco di servizi Web da un lato e un mucchio di pagine web dall'altro.

Esempio: sei un creatore di un altro Facebook. C'è un sito Web e c'è un'API. L'unico punto comune è che viene utilizzato lo stesso database, ma i bot non possono accedere a ciò che le persone possono, e le informazioni sono presentate in modo diverso.

link mostra la top ten degli amici che ho nel mio account. Facendo clic su "Altro", viene effettuata una richiesta AJAX, che mostra altri amici.
link mostra l'XML corrispondente con tutti gli amici che ho.

Puoi vedere che:

• L'API è ospitata separatamente, su un server distinto,
• La relazione tra pagine e API è difficile da vedere.
• Il sito web deve utilizzare le sessioni per tracciare gli accessi. L'API richiede solo una chiave generata da inviare su ogni richiesta.
• Il numero di richieste non è lo stesso. In un caso, devi interrogare la pagina, quindi fare una richiesta AJAX per ottenere il resto dei tuoi amici. In altri casi, si ottiene l'intero elenco in una volta.
• Le informazioni restituite non sono le stesse. Come umano, identifica i tuoi amici con il loro nome. Un bot che utilizza l'API li identificherà in base al loro identificatore univoco che potresti non vedere sul sito web.

Raccomando di scegliere XSLT solo se sei vicino a una relazione 1: 1 . In questo caso, semplificherà l'approccio: l'applicazione emetterà XML ogni volta, ma a volte lo trasformerà con XSLT per i browser.

Se non si dispone di questa relazione, non vedo alcun vantaggio di XSLT su Razor. Fornisce una separazione delle preoccupazioni che fornisce anche Razor. Ti permette di modificare l'HTML senza la necessità di ricompilare il sito web, che consente anche a Razor.

Per quanto riguarda i benefici elencati:

XSLT is a standard and will still exist many years into the future

Hai intenzione di realizzare un'applicazione che vivrà per un tempo molto lungo? Il rasoio ha la possibilità di essere usato in quattro anni, o almeno essere supportato. La durata della maggior parte delle applicazioni è inferiore a quattro anni, quindi ...

Easer for non programmers (something which i could contend with).

Aspetta, cosa ?! Persino i programmatori scoprono che XSLT fa schifo, è difficile da capire e da usare. E quando parlo con i non programmatori di XML (nemmeno vicino a XSLT), piangono e scappano.

It's been successful in some of our past projects.

Se il tuo team non ha mai usato Razor in precedenza, prendi in considerazione il tempo necessario per apprenderlo.

Se il tuo team lo ha usato, ma i progetti non sono andati a buon fine, considera l'analisi del perché è fallito e lo è stato a causa di Razor e cosa potresti fare per evitare tali guasti nei progetti futuri.

La mia raccomandazione è Razor e la ragione principale è che è molto più facile lavorare con (rispetto a XSLT, e al contrario del tuo argomento enumerato a favore di XSLT, però, tu sei dalla mia parte ). Ho esperienza di lavoro con entrambi e Razor diventa eccezionalmente potente in istruzioni condizionali, helper dichiarativi (funzioni principali), branching, looping, ecc.

Dopotutto, non dimentichiamo che Razor è un linguaggio di programmazione (sì, un motore di template o un motore di visualizzazione, ma implementato tramite un linguaggio di programmazione come C # o VB.NET), mentre XSLT ha più una struttura di markup.

Penso che il tuo scenario sia come provare a selezionare C # o T-SQL per scrivere un'applicazione aziendale complessa. Mentre T-SQL è piuttosto potente nelle operazioni di set, si interrompe semplicemente quando si tenta di implementare la logica (if-else, switch, for, ecc.).

Non devi scegliere, puoi usare entrambi. In ASP.NET MVC è possibile utilizzare più motori di visualizzazione contemporaneamente. Nel progetto in cui sto lavorando sto usando XSLT per le visualizzazioni readonly e Razor for forms. Puoi anche utilizzare XSLT con layout Razor o Razor con layout XSLT. Sto usando il layout XSLT, quindi uso semplicemente un layout Razor che chiama il layout XSLT e passa le sezioni HTML come parametri:

@{ 
   Html.RenderPartial("~/Views/shared/htmlRaw.xsl", null, new ViewDataDictionary { 
      { "head", RenderSection("head", required: false) },
      { "content", RenderBody().ToString() }
   });
}

... e in htmlRaw.xsl devi semplicemente usare disable-output-escaping="yes" :

<div id="content">
   <xsl:value-of select="$content" disable-output-escaping="yes"/>
</div>

Vedi Uso di Razor e XSLT nello stesso progetto .

Suggerirei che c'è un terzo e migliore modo: mettere due front end sottili diversi su un singolo livello di servizio / applicazione che non ha UI in quanto tale.

Quindi, piuttosto che

UI -> converts to and from xml -> Service -> talks to -> Application Layer -> Model

utilizzo

UI -> talks to -> Application Layer -> manipulates -> Model
Service ^

e assicurati che l'interfaccia utente e il servizio contengano codice SOLO che sia univoco per quell'interfaccia. (mi scuso per i diagrammi ASCII, meglio che posso fare adesso)

Il motivo per cui sarei preoccupato per entrambi i progetti che stai discutendo è che lega lo sviluppo dell'interfaccia utente allo sviluppo del servizio, che è raramente il modo in cui vuoi lavorare. Se l'azienda vuole aggiungere una parte di funzionalità all'interfaccia utente, non si vuole essere costretti a scrivere quel servizio prima di poterlo fare. Vuoi scrivere la parte dell'interfaccia utente e poi, supponendo che sia richiesta nel servizio, riutilizzare il codice lì.

Peggio ancora, se l'azienda vuole mostrare i dati in modo molto diverso all'utente finale da come viene presentata a un utente meccanico tramite il servizio (che sembra altamente probabile), dovrai iniziare a inserire un codice complesso XSLT o crea un secondo livello di servizio (o peggio, grossi controller) in cima al tuo servizio per rappresentare la presentazione all'utente.

Pensa alla convalida in questo caso. Stai potenzialmente tracciando tre livelli di fiducia. Il tuo modello richiederà la convalida per essere sicuro di non archiviare dati non validi; allora il tuo servizio potrebbe richiedere un po 'più di convalida, per garantire che i consumatori esterni non provino a fare qualcosa che non sono autorizzati a fare; e la tua interfaccia utente avrà bisogno di alcune regole di convalida, nel migliore dei casi in modo che possa evitare un postback.

E questo è prima ancora che tocchiamo la situazione appiccicosa di qualcosa che non dovrebbe essere consentito attraverso l'API, ma dovrebbe essere consentito attraverso l'interfaccia utente, che richiede l'API.

Ho sentito un argomento secondo cui l'esecuzione dell'interfaccia utente attraverso il tuo servizio è dogfooding e quindi utile per la qualità del servizio, ma suggerisco caldamente che ci siano modi migliori per farlo mantenendo una solida (e SOLIDA) separazione delle preoccupazioni tra il servizio, l'interfaccia utente e il modello di business.

Tutto ciò detto, se devi seguire il modo di avvolgere il tuo servizio con un'interfaccia utente, ti consiglio vivamente Razor su XSLT.

XSLT è uno standard, sì. Ma XSLT 2.0 ha ancora un supporto limitato, quindi sei bloccato con uno standard obsoleto se vuoi fare questo argomento.

XSLT non è facile da leggere. Da parte di chiunque non sia un esperto XSLT. Chi pensi sia più facile da trovare, quando hai bisogno di assumere nuovo personale? Qualcuno dichiara di essere un esperto XSLT o un esperto di ASP.NET per MVC?

E sì, ho visto XSLT usato con successo, ma solo prima che MVC per ASP.NET fosse un'opzione.