Razor o XSLT è migliore per il mio progetto? [chiuso]

Sono nelle prime fasi della progettazione di un sistema che sarà essenzialmente diviso in due parti. Una parte è un servizio e l'altra è un'interfaccia con il servizio che fornisce dati attraverso qualcosa come OData o XML. L'applicazione si baserà sul modello architettonico MVC. Per le viste, stiamo considerando l'utilizzo di XSLT o Razor in ASP.NET.

XSLT o Razor aiuterebbe a fornire una separazione delle preoccupazioni in cui l'XML originale o la risposta rappresentano il tuo modello, la XSLT o 'Razor view' rappresenta la tua vista. Lascerò fuori il controller per questo esempio. La proposta di progettazione iniziale raccomanda XSLT, tuttavia ho suggerito l'uso di Razor come motore di visualizzazione più intuitivo.

Questi sono i motivi che ho suggerito per Razor (C #):

• Più facile da lavorare e creare pagine più complicate.
• Può produrre facilmente output non * ML, ad esempio csv, txt, fdf
• Modelli meno dettagliati
• Il modello di visualizzazione è fortemente tipizzato, in cui XSLT dovrebbe fare affidamento su convenzioni, ad esempio valori booleani o di data
• Il markup è più accessibile, ad esempio nbsp, normalizzazione newline, normalizzazione valori valore, regole degli spazi bianchi
• L'helper HTML incorporato può generare un codice di convalida JS basato sugli attributi DTO
• L'helper HTML incorporato può generare collegamenti ad azioni

E gli argomenti per XSLT sul rasoio erano:

• XSLT è uno standard e esisterà ancora molti anni nel futuro.
• È difficile spostare accidentalmente la logica nella vista
• Easer per non programmatori (con cui non sono d'accordo).
• Ha avuto successo in alcuni dei nostri progetti passati.
• I valori dei dati sono codificati in HTML per impostazione predefinita
• Sempre ben formato

Quindi sto cercando strumenti su entrambi i lati, raccomandazioni o esperienze che fanno una scelta simile?

Io HO usato con successo XSLT come una presentazione di livello Web ... nel 1999. Negli ultimi 12 anni, molto meglio le opzioni sono venuti insieme. Fatti un grande favore e usa Razor. È un piacere.

Ecco un confronto di sintassi di base

Rasoio

@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:

• Forte correlazione: ogni pagina Web ha un 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 è prevista alcuna registrazione. Vuoi semplificare l'utilizzo del tuo sito Web a livello di codice 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ò fare: con le stesse richieste, otterranno lo stesso contenuto.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau è utilizzato dall'uomo.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml viene utilizzato dai robot per accedere alle stesse informazioni.

• Correlazione debole o assente: c'è solo un mucchio 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 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.

http://example.com/MyFriends/ mostra i primi dieci amici che ho nel mio account. Facendo clic su "Altro", viene effettuata una richiesta AJAX, che mostra altri amici.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml mostra l'XML corrispondente con tutti gli amici che ho.

Potete vederlo:

• 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 tenere traccia degli accessi. L'API richiede solo una chiave generata per essere inviata ad 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, ottieni l'intero elenco in una volta.
• Le informazioni restituite non sono le stesse. Come essere umano, identifichi i tuoi amici con il loro nome. Un bot che utilizza l'API li identificherà con il loro identificatore univoco che potresti non vedere mai sul sito web.

Consiglio 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 hai questa relazione, non vedo alcun vantaggio di XSLT su Razor. Fornisce una separazione delle preoccupazioni fornite anche da Razor. Ti permette di modificare HTML senza la necessità di ricompilare il sito Web, cosa che Razor consente anche.

Per quanto riguarda i vantaggi elencati:

XSLT è uno standard e esisterà ancora molti anni nel futuro

Stai pensando di fare una domanda che durerà a lungo? Il rasoio ha possibilità di essere utilizzato in quattro anni o almeno di essere supportato. La durata della maggior parte delle applicazioni è inferiore a quattro anni, quindi ...

Easer per non programmatori (qualcosa con cui potrei confrontarmi).

Aspetta cosa?! Anche 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.

Ha avuto successo in alcuni dei nostri progetti passati.

Se la tua squadra non ha mai usato Razor prima, considera il tempo necessario per impararlo.

Se il tuo team lo ha utilizzato, ma quei progetti hanno fallito, prendi in considerazione l'analisi del motivo per cui è fallito ed è stato a causa di Razor, e cosa potresti fare per evitare tali fallimenti nei progetti futuri.

La mia raccomandazione è Razor e il motivo principale è che è molto più facile lavorare con (rispetto a XSLT, e al contrario del tuo argomento elencato a favore di XSLT, però, sei dalla mia parte). Ho esperienza di lavoro con entrambi e Razor diventa eccezionalmente potente in dichiarazioni condizionali, aiutanti dichiarativi (funzioni in principio), ramificazione, loop, ecc.

Dopotutto, non dimentichiamo che Razor è un linguaggio di programmazione (sì, un motore modello o 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 su cui sto attualmente lavorando sto usando XSLT per visualizzazioni di sola lettura e Razor per moduli. Puoi anche usare 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.xslte usa semplicemente 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 esiste un terzo e migliore modo: mettere due diversi front-end sottili sopra un singolo livello di servizio / applicazione che non ha un'interfaccia utente in quanto tale.

Quindi, piuttosto che

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

uso

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

e assicurarsi che l'interfaccia utente e il servizio contengano SOLO codice univoco per tale interfaccia. (mi scuso per i diagrammi ASCII, meglio che posso fare ora)

Il motivo per cui sarei preoccupato per uno dei progetti di cui stai discutendo è che lega lo sviluppo dell'interfaccia utente allo sviluppo del servizio, che raramente è il modo in cui vuoi lavorare. Se l'azienda desidera aggiungere una funzionalità all'interfaccia utente, non è necessario essere obbligati a scrivere quel servizio prima di poterlo fare. Si desidera scrivere la parte dell'interfaccia utente e quindi, supponendo che sia necessaria nel servizio, riutilizzare il codice lì.

Peggio ancora, se l'azienda desidera visualizzare i dati in modo molto diverso rispetto all'utente finale da come vengono presentati a un utente meccanico tramite il servizio (che sembra altamente probabile), dovrai iniziare a inserire codice complesso in XSLT, oppure costruire un secondo livello di servizio (o peggio, controller di grasso) in cima al servizio per rappresentare la presentazione per l'utente.

Pensa alla validazione in questo caso. Stai potenzialmente disegnando tre livelli di fiducia. Il modello richiederà la convalida per assicurarsi di non archiviare dati non validi; quindi il tuo servizio potrebbe richiedere un po 'più di convalida, per garantire che i consumatori esterni non provino a fare qualcosa che non possono fare; e l'interfaccia utente avrà bisogno di alcune regole di convalida, nella migliore delle ipotesi per evitare un postback.

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

Ho sentito l'argomentazione secondo cui far funzionare la tua interfaccia utente attraverso il tuo servizio è cibo per cani e quindi buono per la qualità del servizio, ma suggerisco vivamente che ci sono modi migliori per farlo mantenendo una solida (e SOLIDA) separazione delle preoccupazioni tra il servizio, l'interfaccia utente e il modello di business.

Detto questo, se dovessi seguire il percorso del tuo servizio con un'interfaccia utente, 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 argomentare.

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

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