¿Razor o XSLT son mejores para mi proyecto? [cerrado]

Estoy en las primeras etapas del diseño de un sistema que se dividirá esencialmente en dos partes. Una parte es un servicio y la otra es una interfaz con el servicio que proporciona datos a través de algo como OData o XML. La aplicación se basará en el patrón arquitectónico MVC. Para las vistas, estamos considerando usar XSLT o Razor en ASP.NET.

XSLT o Razor ayudarían a proporcionar una separación de las preocupaciones en las que el XML original o la respuesta representa su modelo, el XSLT o 'Razor view' representa su vista. Dejaré el controlador fuera para este ejemplo. La propuesta de diseño inicial recomienda XSLT, sin embargo, sugerí el uso de Razor como un motor de visualización más amigable.

Estas son las razones que sugerí para Razor (C #):

• Es más fácil trabajar y construir páginas más complicadas.
• Puede producir fácilmente salidas que no sean * ML, por ejemplo, csv, txt, fdf
• Plantillas menos detalladas
• El modelo de vista está fuertemente tipado, donde XSLT necesitaría confiar en la convención, por ejemplo, valores booleanos o de fecha
• El marcado es más accesible, por ejemplo, nbsp, normalización de nueva línea, normalización de valor de atributo, reglas de espacios en blanco
• El asistente HTML integrado puede generar código de validación JS basado en atributos DTO
• El asistente HTML integrado puede generar enlaces a acciones

Y los argumentos para XSLT sobre la maquinilla de afeitar fueron:

• XSLT es un estándar y seguirá existiendo muchos años en el futuro.
• Es difícil mover accidentalmente la lógica a la vista
• Más fácil para los no programadores (con lo que no estoy de acuerdo).
• Ha tenido éxito en algunos de nuestros proyectos pasados.
• Los valores de datos están codificados en HTML de forma predeterminada
• Siempre bien formado

Entonces, ¿estoy buscando aguilones a ambos lados, recomendaciones o alguna experiencia haciendo una elección similar?

Me HE utilizado con éxito XSLT como una capa de presentación web ... en 1999. En los últimos 12 años, mucho mejores opciones tienen venga. Hazte un gran favor y usa Razor. Es un placer.

Aquí hay una comparación básica de sintaxis

Maquinilla de afeitar

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

Las fuentes de datos para los dos ejemplos.

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 una relación 1: 1 entre las páginas HTML y la salida XML? Considere los siguientes casos:

• Fuerte correlación: cada página web tiene un HTML y un formulario XML correspondiente.

Ejemplo: está alojando un sitio web con críticas de películas. Tiene una página de inicio con las últimas reseñas, una página por reseña y una página con comentarios y calificaciones de los huéspedes. No hay registro alguno. Desea facilitar el uso de su sitio web mediante programación sin el desagradable análisis HTML. En este caso, puede tener una relación 1: 1: todo lo que el humano puede hacer, el bot también puede hacerlo: con las mismas solicitudes, obtendrán el mismo contenido.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau es utilizado por humanos.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml es utilizado por bots para acceder a la misma información.

• Correlación débil o nula: solo hay un montón de servicios web por un lado y un montón de páginas web por el otro.

Ejemplo: eres creador de otro Facebook. Hay un sitio web y hay una API. El único punto común es que se utiliza la misma base de datos, pero los bots no pueden acceder a lo que las personas pueden acceder, y la información se presenta de manera diferente.

http://example.com/MyFriends/ muestra los diez mejores amigos que tengo en mi cuenta. Al hacer clic en "Más", se realiza una solicitud AJAX, que muestra a otros amigos.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml muestra el XML correspondiente con todos los amigos que tengo.

Puedes ver eso:

• La API se aloja por separado, en un servidor distinto,
• La relación entre páginas y API es difícil de ver.
• El sitio web necesita usar sesiones para rastrear los inicios de sesión. La API solo necesita que se envíe una clave generada en cada solicitud.
• El número de solicitudes no es el mismo. En un caso, debe consultar la página, luego hacer una solicitud AJAX para obtener el resto de sus amigos. En otro caso, obtienes la lista completa de una vez.
• La información devuelta no es la misma. Como humano, identificas a tus amigos por su nombre. Un bot que use la API los identificará por su identificador único que nunca verá en el sitio web.

Recomiendo elegir XSLT solo si está cerca de una relación 1: 1 . En este caso, simplificará el enfoque: la aplicación emitirá XML cada vez, pero a veces lo transformará con XSLT para los navegadores.

Si no tiene esta relación, no veo ningún beneficio de XSLT sobre Razor. Proporciona una separación de preocupaciones que Razor también proporciona. Le permite modificar HTML sin la necesidad de volver a compilar el sitio web, lo que Razor también permite.

En cuanto a los beneficios que enumeró:

XSLT es un estándar y seguirá existiendo muchos años en el futuro

¿Estás planeando hacer una aplicación que vivirá por mucho tiempo? Razor tiene posibilidades de ser utilizado en cuatro años, o al menos ser compatible. La vida útil de la mayoría de las aplicaciones es inferior a cuatro años, así que ...

Más fácil para los no programadores (algo con lo que podría lidiar).

¡¿Esperar lo?! Incluso los programadores encuentran que XSLT apesta, es difícil de entender y usar. Y cuando hablo con no programadores sobre XML (ni siquiera cerca de XSLT), lloran y huyen.

Ha tenido éxito en algunos de nuestros proyectos pasados.

Si su equipo nunca usó Razor antes, considere el tiempo requerido para aprenderlo.

Si su equipo lo usó, pero esos proyectos fallaron, considere analizar por qué falló y se debió a Razor, y qué podría hacer para evitar tales fallas en proyectos futuros.

Mi recomendación es Razor y la razón principal es que es mucho más fácil trabajar con él (que con XSLT, y opuesto a su argumento enumerado a favor de XSLT, sin embargo, usted está de mi lado). Tengo experiencia trabajando con ambos y Razor se vuelve excepcionalmente poderoso en declaraciones condicionales, ayudantes declarativos (funciones en principal), ramificaciones, bucles, etc.

Después de todo, no olvidemos que Razor es un lenguaje de programación (sí, un motor de plantillas o un motor de visualización, pero implementado a través de un lenguaje de programación como C # o VB.NET), mientras que XSLT tiene más una estructura de marcado.

Creo que su escenario es como tratar de seleccionar C # o T-SQL para escribir una aplicación comercial compleja. Si bien T-SQL es bastante poderoso en las operaciones de conjuntos, simplemente se rompe cuando intenta implementar la lógica (if-else, switch, for, etc.) en él.

No tiene que elegir, puede usar ambos. En ASP.NET MVC puede usar múltiples motores de vista al mismo tiempo. En el proyecto en el que estoy trabajando actualmente, estoy usando XSLT para vistas de solo lectura y Razor para formularios. También puede usar XSLT con diseño Razor o Razor con diseño XSLT. Estoy usando el diseño XSLT, así que simplemente uso un diseño Razor que llama al diseño XSLT y pasa las secciones HTML como parámetros:

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

... y htmlRaw.xslsimplemente usas disable-output-escaping="yes":

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

Consulte Uso de Razor y XSLT en el mismo proyecto .

Sugeriría que hay una tercera y mejor manera: poner dos frontales delgados diferentes en la parte superior de una sola capa de servicio / aplicación que no tiene interfaz de usuario como tal.

Entonces, en lugar de

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

utilizar

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

y asegúrese de que la interfaz de usuario y el servicio contengan ÚNICAMENTE código que sea exclusivo de esa interfaz. (disculpas por los diagramas ASCII, lo mejor que puedo hacer ahora)

La razón por la que me preocuparía cualquiera de los diseños que está discutiendo es porque vincula el desarrollo de la interfaz de usuario con el desarrollo del servicio, que rara vez es la forma en que desea trabajar. Si la empresa desea agregar una funcionalidad a la interfaz de usuario, no debe verse obligado a escribir ese servicio antes de poder hacerlo. Desea escribir la parte de la interfaz de usuario y luego, suponiendo que sea necesario en el servicio, reutilice el código allí.

Peor aún, si la empresa quiere mostrar los datos de manera muy diferente al usuario final de la forma en que se presenta a un usuario mecánico a través del servicio (lo que parece muy probable), tendrá que comenzar a poner código complejo en XSLT, o construya una segunda capa de servicio (o peor, controladores gordos) sobre su servicio para representar la presentación al usuario.

Piensa en la validación en este caso. Potencialmente, está atrayendo tres niveles de confianza. Su modelo requerirá validación para asegurarse de que no almacene datos no válidos; entonces su servicio puede requerir más validación, para garantizar que los consumidores externos no intenten hacer algo que no se les permite hacer; y su IU necesitará algunas reglas de validación, en el mejor de los casos, para evitar una devolución de datos.

Y esto es incluso antes de que toquemos la situación difícil de algo que no debería permitirse a través de la API, pero debería permitirse a través de la interfaz de usuario, que requiere la API.

He escuchado un argumento de que ejecutar su interfaz de usuario a través de su servicio es beneficioso para los perros y, por lo tanto, bueno para la calidad del servicio, pero sugiero encarecidamente que haya mejores maneras de hacerlo mientras se mantiene una separación sólida (y SÓLIDA) de las preocupaciones entre el servicio, La interfaz de usuario y el modelo de negocio.

Dicho todo esto, si debe seguir el camino de envolver su servicio con una interfaz de usuario, recomendaría encarecidamente Razor sobre XSLT.

XSLT es un estándar, sí. Pero XSLT 2.0 todavía tiene un soporte limitado, por lo que está atascado con un estándar obsoleto si desea hacer ese argumento.

XSLT no es fácil de leer. Por cualquiera que no sea un experto en XSLT. ¿Quién crees que es más fácil de encontrar cuando necesitas contratar personal nuevo? ¿Alguien que dice ser un experto en XSLT o un experto en ASP.NET para MVC?

Y sí, he visto que XSLT se usó con éxito, pero solo antes de que MVC para ASP.NET fuera una opción.