O Razor ou o XSLT é melhor para o meu projeto? [fechadas]

Estou nos estágios iniciais do design de um sistema que será essencialmente dividido em duas partes. Uma parte é um serviço e a outra é uma interface com o serviço que fornece dados através de algo como OData ou XML. O aplicativo será baseado no padrão de arquitetura MVC. Para as visualizações, estamos considerando usar o XSLT ou o Razor no ASP.NET.

O XSLT ou o Razor ajudaria a fornecer uma separação de preocupações em que o XML ou resposta original representa seu modelo, o XSLT ou 'Razor view' representa sua visão. Vou deixar o controlador de fora para este exemplo. A proposta de design inicial recomenda o XSLT, no entanto, sugeri o uso do Razor como um mecanismo de exibição mais amigável.

Estas são as razões que sugeri para o Razor (C #):

• Mais fácil de trabalhar e criar páginas mais complicadas.
• Pode facilmente produzir saída não * ML, por exemplo, csv, txt, fdf
• Modelos menos detalhados
• O modelo de visualização é fortemente tipado, onde o XSLT precisaria confiar na convenção, por exemplo, valores booleanos ou de data
• A marcação é mais acessível, por exemplo, nbsp, normalização de nova linha, normalização de valor de atributo, regras de espaço em branco
• O auxiliar HTML integrado pode gerar código de validação JS com base nos atributos do DTO
• O auxiliar HTML integrado pode gerar links para ações

E os argumentos para XSLT sobre navalha foram:

• O XSLT é um padrão e ainda existirá muitos anos no futuro.
• É difícil mover acidentalmente a lógica para a visualização
• Mais fácil para não programadores (com os quais não concordo).
• Foi bem-sucedido em alguns de nossos projetos anteriores.
• Os valores dos dados são codificados em HTML por padrão
• Sempre bem formado

Então, eu estou procurando informações de ambos os lados, recomendações ou qualquer experiência que faça uma escolha semelhante?

I TER utilizado com sucesso XSLT como uma camada de apresentação web ... em 1999. Nos últimos 12 anos, muito melhores opções têm vir. Faça um grande favor a si mesmo e use o Razor. É um prazer.

Aqui está uma comparação de sintaxe básica

Navalha

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

As fontes de dados para os dois exemplos

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 uma relação 1: 1 entre páginas HTML e saída XML? Considere os seguintes casos:

• Forte correlação: cada página da web possui um HTML e um formulário XML correspondente.

Exemplo: você está hospedando um site com resenhas de filmes. Você tem uma página inicial com as avaliações mais recentes, uma página por revisão e uma página com comentários e classificações dos hóspedes. Não há registro algum. Você deseja facilitar o uso do site de forma programática, sem a feia análise de HTML. Nesse caso, você pode ter uma relação de 1: 1: tudo que o humano pode fazer, o bot também: com os mesmos pedidos, eles obterão o mesmo conteúdo.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau é usado por humanos.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml é usado pelos bots para acessar as mesmas informações.

• Correlação fraca ou inexistente: há apenas um monte de serviços da web de um lado e várias páginas da Web do outro.

Exemplo: você é criador de outro Facebook. Existe um site e há uma API. O único ponto comum é que o mesmo banco de dados é usado, mas os bots não podem acessar o que as pessoas podem e as informações são apresentadas de maneira diferente.

http://example.com/MyFriends/ mostra os dez melhores amigos que tenho na minha conta. Ao clicar em "Mais", uma solicitação AJAX é feita, mostrando outros amigos.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml mostra o XML correspondente com todos os amigos que tenho.

Você pode ver isso:

• A API é hospedada separadamente, em um servidor distinto,
• A relação entre páginas e API é difícil de ver.
• O site precisa usar sessões para rastrear logons. A API precisa apenas de uma chave gerada para ser enviada a cada solicitação.
• O número de solicitações não é o mesmo. Em um caso, você deve consultar a página e, em seguida, fazer uma solicitação AJAX para obter o restante de seus amigos. Em outro caso, você obtém a lista inteira de uma só vez.
• As informações retornadas não são as mesmas. Como humano, você identifica seus amigos pelo nome deles. Um bot que usa a API os identifica por seu identificador exclusivo, que você pode nunca ver no site.

Eu recomendo escolher o XSLT apenas se você estiver próximo de uma relação 1: 1 . Nesse caso, simplificará a abordagem: o aplicativo emitirá XML todas as vezes, mas às vezes o transformará com XSLT para os navegadores.

Se você não tem essa relação, não vejo nenhum benefício do XSLT sobre o Razor. Ele fornece uma separação de preocupações que Razor também oferece. Permite modificar o HTML sem a necessidade de recompilar o site, o que o Razor também permite.

Quanto aos benefícios que você listou:

XSLT é um padrão e ainda existirá muitos anos no futuro

Você está planejando fazer um aplicativo que permanecerá por muito tempo? A navalha tem chances de ser usada em quatro anos, ou pelo menos ser suportada. A vida útil da maioria das aplicações é inferior a quatro anos, então ...

Mais fácil para não programadores (algo que eu poderia enfrentar).

Espere o que?! Até os programadores acham que o XSLT é péssimo, difícil de entender e usar. E quando falo com não programadores sobre XML (nem mesmo perto do XSLT), eles choram e fogem.

Foi bem-sucedido em alguns de nossos projetos anteriores.

Se sua equipe nunca usou o Razor antes, considere o tempo necessário para aprendê-lo.

Se sua equipe o usou, mas esses projetos falharam, considere analisar por que falhou e foi por causa do Razor e o que você poderia fazer para evitar essas falhas em projetos futuros.

Minha recomendação é o Razor e o principal motivo é que é muito mais fácil trabalhar com (do que o XSLT, e ao contrário do seu argumento enumerado em favor do XSLT, você está do meu lado). Tenho experiência em trabalhar com ambos e o Razor se torna excepcionalmente poderoso em declarações condicionais, auxiliares declarativos (funções em principal), ramificação, looping etc.

Afinal, não vamos esquecer que o Razor é uma linguagem de programação (sim, um mecanismo de modelo ou mecanismo de exibição, mas implementado através de uma linguagem de programação como C # ou VB.NET), enquanto o XSLT é mais com uma estrutura de marcação.

Eu acho que o seu cenário é como tentar selecionar C # ou T-SQL para escrever um aplicativo de negócios complexo. Embora o T-SQL seja bastante poderoso em operações de conjunto, ele simplesmente quebra quando você tenta implementar lógica (se-outro, alternar, para etc.) nele.

Você não precisa escolher, pode usar os dois. No ASP.NET MVC, você pode usar vários mecanismos de exibição ao mesmo tempo. No projeto em que estou trabalhando, estou usando o XSLT para visualizações somente leitura e o Razor para formulários. Você também pode usar o XSLT com layout Razor ou o Razor com layout XSLT. Estou usando o layout XSLT, então simplesmente uso um layout Razor que chama o layout XSLT e passa as seções HTML como parâmetros:

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

... e htmlRaw.xslvocê simplesmente usa disable-output-escaping="yes":

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

Consulte Usando o Razor e o XSLT no mesmo projeto .

Eu sugeriria que há uma terceira e melhor maneira: colocar duas extremidades frontais finas diferentes em cima de uma única camada de serviço / aplicativo que não possui interface do usuário.

Então, ao invés de

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

usar

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

e verifique se a interface do usuário e o serviço contêm apenas o código exclusivo dessa interface. (desculpas pelos diagramas ASCII, o melhor que posso fazer agora)

O motivo pelo qual me preocuparia com qualquer um dos projetos que você está discutindo é que ele vincula o desenvolvimento da interface do usuário ao desenvolvimento do serviço, que raramente é como você deseja trabalhar. Se a empresa deseja adicionar uma parte da funcionalidade à interface do usuário, você não deve ser forçado a escrever esse serviço antes de poder fazê-lo. Você deseja gravar a parte da interface do usuário e, supondo que seja necessário no serviço, reutilize o código lá.

Pior ainda, se a empresa deseja exibir dados de maneira muito diferente para o usuário final, de como são apresentados a um usuário mecânico por meio do serviço (o que parece altamente provável), você terá que começar a inserir código complexo no XSLT, ou crie uma segunda camada de serviço (ou pior, controladores de gordura) sobre o seu serviço para representar a apresentação ao usuário.

Pense em validação neste caso. Você está potencialmente atraindo três níveis de confiança. Seu modelo exigirá validação para garantir que você não armazene dados inválidos; seu serviço pode exigir mais validação, para garantir que os consumidores externos não tentem fazer algo que não estão autorizados a fazer; e sua interface do usuário precisará de algumas regras de validação, na melhor das hipóteses, para evitar uma postagem.

E isso é antes mesmo de tocarmos na situação complicada de algo que não deveria ser permitido através da API, mas deveria ser permitido através da interface do usuário, que requer a API.

Ouvi um argumento de que a execução da interface do usuário por meio do serviço é dogfood e, portanto, boa para a qualidade do serviço, mas sugiro fortemente que existem maneiras melhores de fazer isso, mantendo uma separação sólida (e sólida) de preocupações entre o serviço, a interface do usuário e o modelo de negócios.

Tudo isso dito, se você deve seguir o caminho de agrupar seu serviço com uma interface do usuário, eu recomendaria fortemente o Razor sobre o XSLT.

XSLT é um padrão, sim. Mas o XSLT 2.0 ainda tem suporte limitado, então você está preso a um padrão desatualizado se quiser fazer esse argumento.

XSLT não é fácil de ler. Por qualquer pessoa que não seja especialista em XSLT. Quem você acha que é mais fácil encontrar quando precisa contratar novos funcionários? Alguém que afirma ser um especialista em XSLT ou um especialista em ASP.NET for MVC?

E sim, vi o XSLT ser usado com êxito, mas somente antes do MVC para ASP.NET ser uma opção.