存在Razor模板时使用XSL的原因

Question

有没有充分的理由继续使用XSL模板，因为Razor模板引擎存在？

从我所看到的：

1. Razor模板引擎的语法更接近C＃（或VB），这是您已经用于编写服务器代码的语法，而XSL模板具有类似XML的语法，这要求开发人员至少学习XML的基础知识。
2. 您可以直接使用现有的对象模型，而无需先将其转换为XML。
3. Microsoft仅支持XSL 1.0版，因此您似乎可以在XSL中使用哪些功能。

注意：如果您想回答此问题，请尝试避免使用一种语言而非另一种语言的个人原因，并专注于实际原因的技术/实际原因优于另一个优势。你可能已经注意到我已经建立了一个偏好，但我试图尽我所能保持这一点。

更新

在我目前的情况下，我从数据库中获取数据并将其转换为XML ，然后使用XSLT将其转换为有效的HTML，然后呈现给用户。从我的观点来看，直接转换为对象模型似乎更实际，然后可以在Razor模板中使用。就个人而言，我觉得维护和使用比我当前流程更少的代码更容易。然而，在我决定从XSLT转换为Razor之前，我试图给XSLT一个公平的震动，并希望在两者之间进行更直接的比较。 （旁注：这不是我选择的过程，而是我被告知要使用的过程。）

再次，请尽量不要偏离这一点。我的目标是对XSLT和Razor进行技术/实际比较，以便我可以确定哪种技术最适合我的情况。

Answer 1

我在一个在开发基于ASP.NET表单的应用程序时严重依赖XSL的组织工作。当他们搬到MVC / Razor时，XSL完全掉线了。主要是因为您列出的原因1和2。从维护的角度来看，使用Razor更容易，因为进入组织的新开发人员可以比XSL更容易拿起Razor，并且更有可能已经拥有Razor技能而不是XSL。在对象和XML之间来回转换需要更多的编码，并且使用对象允许您使用InteliSense，我相信这是一个很大的生产力增益。我还想补充一点，使用Razor更容易调试，它更简洁，更简洁。

Answer 2

嗯，首先，有很多人与一个平台紧密相关的解决方案是非首发的，要么是因为他们不使用该平台，要么是因为他们不想与之相关联。您认为C＃/ VB是“您已经用于编写服务器代码的内容”的假设肯定只适用于您的一小部分受众。

然后，有些人开始重视基于声明规则的高级声明方法所带来的好处，而不是被熟悉的低级程序编码所诱惑。当然那些程序编码根本不熟悉的人。

同意，在对象和XML之间移动可能会很痛苦。对于许多人来说，答案是不让数据到达对象附近。当您承诺使用基于XML的技术编写整个应用程序时，XSLT（你通过调用它来欺骗你的无知）最好用C＃或Java只用于管道。

但语言的选择始终是品味的问题。人们很少做出客观的循证决策。时尚占上风;通常，新项目的风险最低的方法是使用您最了解的任何方法。

Answer 3

这取决于你的问题是什么？我们使用XSLT转换在各种系统之间交换的XML消息文档。

通常我们的XLST在Java EE引擎中执行。

所以我们不是MVC / Microsoft用例附近的任何地方。不可否认，我只是简单地看了一下Razor，但它似乎与我们的问题领域没什么关系。