Razor ou XSLT est-il meilleur pour mon projet? [fermé]

Je suis aux premiers stades de la conception d'un système qui sera essentiellement divisé en deux parties. Une partie est un service et l'autre est une interface avec le service fournissant des données via quelque chose comme OData ou XML. L'application sera basée sur le modèle architectural MVC. Pour les vues, nous envisageons d'utiliser XSLT ou Razor sous ASP.NET.

XSLT ou Razor aideraient à fournir une séparation des préoccupations lorsque le XML ou la réponse d'origine représente votre modèle, le XSLT ou «Razor view» représente votre vue. Je laisse le contrôleur hors de cet exemple. La proposition de conception initiale recommande XSLT, mais j'ai suggéré l'utilisation de Razor à la place comme moteur de visualisation plus convivial.

Ce sont les raisons que j'ai suggérées pour Razor (C #):

• Plus facile à utiliser et à créer des pages plus compliquées.
• Peut facilement produire une sortie non * ML, par exemple csv, txt, fdf
• Modèles moins verbeux
• Le modèle de vue est fortement typé, où XSLT devrait s'appuyer sur des conventions, par exemple des valeurs booléennes ou de date
• Le balisage est plus accessible, par exemple nbsp, normalisation de nouvelle ligne, normalisation de valeur d'attribut, règles d'espaces blancs
• Un assistant HTML intégré peut générer du code de validation JS basé sur les attributs DTO
• Un assistant HTML intégré peut générer des liens vers des actions

Et les arguments pour XSLT sur le rasoir étaient:

• XSLT est une norme et existera encore de nombreuses années dans le futur.
• Il est difficile de déplacer accidentellement la logique dans la vue
• Easer pour les non programmeurs (avec lequel je ne suis pas d'accord).
• Il a réussi dans certains de nos projets antérieurs.
• Les valeurs des données sont encodées en HTML par défaut
• Toujours bien formé

Je recherche donc des arguments de part et d'autre, des recommandations ou toute expérience faisant un choix similaire?

J'AI utilisé avec succès XSLT comme couche de présentation Web ... en 1999. Au cours des 12 dernières années, beaucoup de meilleures options ont venir le long. Rendez-vous service et utilisez Razor. C'est un plaisir.

Voici une comparaison de syntaxe de base

Rasoir

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

Les sources de données pour les deux exemples

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"
    }
};

Existe-t-il une relation 1: 1 entre les pages HTML et la sortie XML? Considérez les cas suivants:

• Forte corrélation: chaque page Web a un HTML et un formulaire XML correspondant.

Exemple: vous hébergez un site Web avec des critiques de films. Vous avez une page d'accueil avec les derniers avis, une page par avis et une page avec les commentaires et les notes des clients. Il n'y a aucune inscription. Vous voulez faciliter l'utilisation de votre site Web par programmation sans laide analyse HTML. Dans ce cas, vous pouvez avoir une relation 1: 1: tout ce que l'humain peut faire, le bot peut le faire aussi: avec les mêmes requêtes, ils obtiendront le même contenu.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau est utilisé par les humains.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml est utilisé par les bots pour accéder aux mêmes informations.

• Corrélation faible ou inexistante: il y a juste un tas de services Web d'un côté et un tas de pages Web de l'autre.

Exemple: vous êtes un créateur d'un autre Facebook. Il y a un site Web et une API. Le seul point commun est que la même base de données est utilisée, mais les robots ne peuvent pas accéder à ce que les gens peuvent et les informations sont présentées différemment.

http://example.com/MyFriends/ affiche le top 10 des amis que j'ai dans mon compte. En cliquant sur "Plus", une demande AJAX est faite, montrant d'autres amis.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml montre le XML correspondant avec tous mes amis que j'ai.

Tu peux voir ça:

• L'API est hébergée séparément, sur un serveur distinct,
• La relation entre les pages et l'API est difficile à voir.
• Le site Web doit utiliser des sessions pour suivre les connexions. L'API n'a besoin que d'une clé générée pour être envoyée à chaque demande.
• Le nombre de demandes n'est pas le même. Dans un cas, vous devez interroger la page, puis faire une demande AJAX pour obtenir le reste de vos amis. Dans les autres cas, vous obtenez la liste complète en une seule fois.
• Les informations retournées ne sont pas les mêmes. En tant qu'humain, vous identifiez vos amis par leur nom. Un bot utilisant l'API les identifiera par leur identifiant unique que vous ne verrez peut-être jamais sur le site.

Je recommande de choisir XSLT uniquement si vous êtes proche d'une relation 1: 1 . Dans ce cas, cela simplifiera l'approche: l'application émettra du XML à chaque fois, mais la transformera parfois avec XSLT pour les navigateurs.

Si vous n'avez pas cette relation, je ne vois aucun avantage de XSLT sur Razor. Il fournit une séparation des préoccupations que Razor fournit également. Il vous permet de modifier le HTML sans avoir besoin de recompiler le site Web, ce que Razor permet également.

Quant aux avantages que vous avez énumérés:

XSLT est une norme et existera encore de nombreuses années dans le futur

Envisagez-vous de faire une application qui va vivre très longtemps? Le rasoir a des chances d'être utilisé dans quatre ans, ou au moins d'être pris en charge. La durée de vie de la plupart des applications est inférieure à quatre ans, donc ...

Easer pour les non programmeurs (quelque chose que je pourrais affronter).

Attends quoi?! Même les programmeurs trouvent que XSLT est nul, difficile à comprendre et à utiliser. Et quand je parle à des non-programmeurs de XML (pas même proche de XSLT), ils pleurent et s'enfuient.

Il a réussi dans certains de nos projets antérieurs.

Si votre équipe n'a jamais utilisé Razor auparavant, considérez le temps nécessaire pour l'apprendre.

Si votre équipe l'a utilisé, mais que ces projets ont échoué, envisagez d'analyser pourquoi il a échoué et était-ce à cause de Razor, et que pourriez-vous faire pour éviter de tels échecs dans les projets futurs.

Ma recommandation est Razor et la raison principale est qu'il est beaucoup plus facile de travailler avec (qu'avec XSLT, et contrairement à votre argument énuméré en faveur de XSLT, cependant, vous êtes de mon côté). J'ai l'expérience de travailler avec les deux et Razor devient exceptionnellement puissant dans les instructions conditionnelles, les assistants déclaratifs (fonctions en principal), les branchements, les boucles, etc.

Après tout, n'oublions pas que Razor est un langage de programmation (oui, un moteur de modèle ou un moteur de vue, mais implémenté via un langage de programmation comme C # ou VB.NET), tandis que XSLT a plutôt une structure de balisage.

Je pense que votre scénario revient à essayer de sélectionner C # ou T-SQL pour écrire une application métier complexe. Bien que T-SQL soit assez puissant dans les opérations de définition, il se casse simplement lorsque vous essayez d'implémenter une logique (if-else, switch, for, etc.).

Vous n'avez pas à choisir, vous pouvez utiliser les deux. Dans ASP.NET MVC, vous pouvez utiliser plusieurs moteurs de vue en même temps. Dans le projet sur lequel je travaille actuellement, j'utilise XSLT pour les vues en lecture seule et Razor pour les formulaires. Vous pouvez également utiliser XSLT avec la disposition Razor ou Razor avec la disposition XSLT. J'utilise la disposition XSLT, j'utilise donc simplement une disposition Razor qui appelle la disposition XSLT et transmet les sections HTML en tant que paramètres:

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

... et en htmlRaw.xslvous utilisez simplement disable-output-escaping="yes":

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

Voir Utilisation de Razor et XSLT dans le même projet .

Je dirais qu'il existe une troisième et meilleure façon: mettre deux frontaux minces différents au-dessus d'une seule couche service / application qui n'a pas d'interface utilisateur en tant que telle.

Donc, plutôt que

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

utilisation

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

et assurez-vous que l'interface utilisateur et le service contiennent UNIQUEMENT du code unique à cette interface. (excuses pour les diagrammes ASCII, le mieux que je puisse faire pour le moment)

La raison pour laquelle je serais préoccupé par l'une des conceptions dont vous discutez est qu'elle lie le développement de l'interface utilisateur au développement du service, ce qui est rarement la façon dont vous voulez travailler. Si l'entreprise souhaite ajouter un élément de fonctionnalité à l'interface utilisateur, vous ne voulez pas être obligé d'écrire ce service avant de pouvoir le faire. Vous souhaitez écrire la partie d'interface utilisateur, puis, en supposant qu'elle soit requise dans le service, réutiliser le code là-bas.

Pire, si l'entreprise souhaite afficher les données de manière très différente pour l'utilisateur final de la façon dont elles sont présentées à un utilisateur mécanique via le service (ce qui semble très probable), vous allez devoir commencer à mettre du code complexe dans XSLT, ou créez une deuxième couche de service (ou pire, de gros contrôleurs) au-dessus de votre service pour représenter la présentation à l'utilisateur.

Pensez à la validation dans ce cas. Vous dessinez potentiellement trois niveaux de confiance. Votre modèle devra être validé pour vous assurer que vous ne stockez pas de données non valides; votre service peut alors nécessiter une validation supplémentaire, pour garantir que les consommateurs externes n'essaient pas de faire quelque chose qu'ils ne sont pas autorisés à faire; et votre interface utilisateur aura besoin de quelques règles de validation, au mieux afin d'éviter un postback.

Et c'est avant même de toucher à la situation délicate de quelque chose qui ne devrait pas être autorisé via l'API mais devrait l'être via l'interface utilisateur, ce qui nécessite l'API.

J'ai entendu un argument selon lequel l'exécution de votre interface utilisateur via votre service est un aliment pour chiens et donc bon pour la qualité du service, mais je suggère fortement qu'il existe de meilleures façons de le faire tout en gardant une séparation solide (et SOLIDE) des préoccupations entre le service, l'interface utilisateur et le modèle d'entreprise.

Cela dit, si vous devez suivre la voie de l'emballage de votre service avec une interface utilisateur, je recommanderais fortement Razor plutôt que XSLT.

XSLT est un standard, oui. Mais XSLT 2.0 a toujours un support limité, donc vous êtes coincé avec une norme obsolète si vous voulez faire cet argument.

XSLT n'est pas facile à lire. Par toute personne qui n'est pas un expert XSLT. Selon vous, qui est le plus facile à trouver lorsque vous avez besoin d'embaucher du nouveau personnel? Quelqu'un prétendant être un expert XSLT ou un expert ASP.NET pour MVC?

Et oui, j'ai vu XSLT utilisé avec succès, mais seulement avant que MVC pour ASP.NET ne soit une option.