Razor或XSLT是否更适合我的项目？[关闭]

我正处于系统设计的初期阶段，该系统实际上将分为两部分。一个部分是服务，另一部分是与服务的接口，该接口通过OData或XML之类的数据提供数据。该应用程序将基于MVC架构模式。对于视图，我们正在考虑在ASP.NET下使用XSLT或Razor。

XSLT或Razor将有助于分离关注点，其中原始XML或响应表示您的模型，XSLT或“ Razor视图”表示您的视图。在本示例中，我将省略控制器。最初的设计建议建议使用XSLT，但是我建议使用Razor作为更友好的视图引擎。

这些是我建议使用Razor（C＃）的原因：

• 更易于使用和构建更复杂的页面。
• 可以轻松产生非* ML输出，例如csv，txt，fdf
• 不太冗长的模板
• 视图模型是强类型的，其中XSLT需要依赖约定，例如布尔值或日期值
• 标记更易于访问，例如nbsp，换行符标准化，服装值标准化，空白规则
• 内置的HTML帮助程序可以基于DTO属性生成JS验证代码
• 内置的HTML帮助程序可以生成操作的链接

对于剃须刀而言，XSLT的论点是：

• XSLT是一个标准，并且在将来仍会存在很多年。
• 很难不小心将逻辑移到视图中
• 对于非程序员更轻松（我不同意）。
• 在我们过去的一些项目中，它是成功的。
• 数据值默认为HTML编码
• 始终保持良好状态

因此，我正在寻找双方的观点，建议或做出类似选择的经验？

我兹成功地使用XSLT作为Web表现层...在1999年在过去的12年间，有更好的选择有一起走。帮自己一个大忙，并使用Razor。我的荣幸。

这是基本语法比较

剃刀

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

两个示例的数据源

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

HTML页面和XML输出之间是否存在1：1的关系？考虑以下情况：

• 高度相关：每个网页都有一个HTML和一个对应的XML形式。

示例：您正在托管一个带有电影评论的网站。您有一个包含最新评论的主页，每个评论一个页面，以及一个包含来宾评论和评分的页面。没有任何注册。您希望通过编程轻松使用网站，而无需进行难看的HTML解析。在这种情况下，您可以具有1：1的关系：人类可以做的所有，机器人也可以做的：在相同的请求下，他们将获得相同的内容。

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau被人类使用。僵尸程序使用
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml来访问相同的信息。

• 相关性弱或无相关性：一侧只有一堆Web服务，另一侧只有一堆网页。

示例：您是另一个Facebook的创建者。有一个网站，有一个API。唯一的共同点是使用相同的数据库，但是漫游器无法访问人们可以访问的内容，并且信息的显示方式也有所不同。

http://example.com/MyFriends/显示我帐户中排名前十的朋友。通过单击“更多”，发出AJAX请求，显示其他朋友。
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml与我拥有的所有朋友一起显示相应的XML。

您可以看到：

• 该API分别托管在不同的服务器上，
• 页面和API之间的关系很难看清。
• 该网站需要使用会话来跟踪登录。API仅需要在每个请求上发送生成的密钥。
• 请求数不相同。在一种情况下，您必须查询页面，然后进行AJAX请求才能获得其余的朋友。在其他情况下，您可以一次获取整个列表。
• 返回的信息不相同。作为人类，您可以通过朋友的名字来识别他们。使用该API的漫游器会通过它们的唯一标识符来识别它们，而您在网站上可能永远不会看到它们。

我建议仅在接近1：1关系时才选择XSLT。在这种情况下，它将简化方法：应用程序每次都会发出XML，但有时会使用XSLT将其转换为浏览器。

如果您没有这种关系，那么我认为XSLT与Razor相比没有任何好处。它提供了剃刀也提供的关注点分离。它允许您修改HTML，而无需重新编译网站，Razor也允许。

至于您列出的好处：

XSLT是一个标准，并且在将来仍会存在很多年

您是否打算制作一个可以长期使用的应用程序？剃刀有机会在四年内使用，或至少得到支持。大多数应用程序的寿命不到四年，因此...

对于非程序员更轻松（我可以抗衡的东西）。

等等，什么？甚至程序员都发现XSLT很烂，难以理解和使用。当我与非程序员讨论XML（甚至不接近XSLT）时，他们会哭泣并逃之away。

在我们过去的一些项目中，它是成功的。

如果您的团队以前从未使用过Razor，请考虑学习它的时间。

如果您的团队使用了它，但是那些项目失败了，请考虑分析它为什么失败以及是由于Razor造成的，以及您可以采取什么措施来避免以后的项目中出现此类失败。

我的建议是Razor，主要原因是使用起来要容易得多（比XSLT更容易，并且与您赞成XSLT的列举观点相反，尽管您支持我）。我拥有与两者一起工作的经验，Razor在条件语句，声明性助手（原则上是函数），分支，循环等方面变得异常强大。

毕竟，我们不要忘记Razor是一种编程语言（是的，是模板引擎或视图引擎，但是是通过C＃或VB.NET等编程语言实现的），而XSLT更具有标记结构。

我认为您的情况就像尝试选择C＃或T-SQL来编写复杂的业务应用程序。尽管T-SQL在集合操作中非常强大，但是当您尝试在其中实现逻辑（if-else，switch，for等）时，它只会中断。

您不必选择，可以同时使用。在ASP.NET MVC中，您可以同时使用多个视图引擎。在该项目中，我目前正在使用XSLT用于只读视图，使用Razor用于表单。您还可以将XSLT与Razor布局一起使用，或者将Razor与XSLT布局一起使用。我正在使用XSLT布局，因此我只使用Razor布局来调用XSLT布局并将HTML部分作为参数传递：

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

...而htmlRaw.xsl您只需使用disable-output-escaping="yes"：

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

请参阅在同一项目中使用Razor和XSLT。

我建议有第三种更好的方法：将两个不同的瘦前端放在没有UI这样的单个服务/应用程序层的顶部。

所以，而不是

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

采用

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

并确保UI和服务仅包含该界面唯一的代码。（对ASCII图表示歉意，我现在可以做的最好）

我担心您正在讨论的任何一种设计的原因是，它将用户界面的开发与服务的开发联系在一起，而这几乎是您想要的工作方式。如果企业要向用户界面添加功能，则不希望您在执行该服务之前就被迫编写该服务。您要编写用户界面部分，然后，假设服务中需要它，则在其中重用代码。

更糟糕的是，如果企业想要向最终用户显示与通过服务呈现给机械用户的数据完全不同的数据（这似乎很有可能），那么您将不得不开始将复杂的代码放入XSLT中，或者在您的服务之上构建第二个服务层（或更糟糕的是，胖控制器），以向用户展示内容。

考虑这种情况下的验证。您可能会绘制三个信任级别。您的模型将需要进行验证，以确保您不会存储无效数据。那么您的服务可能需要更多验证，以确保外部使用者不会尝试做他们不允许做的事情；并且您的用户界面最多需要一些验证规则，以便避免回发。

而且这是在我们甚至碰到棘手的情况之前，这种情况不应通过API允许，而应通过需要API的UI允许。

我曾听到一个论点，认为通过服务运行UI令人反感，因此有利于服务质量，但我强烈建议您采取更好的方法，同时将服务之间的关注点保持牢固（和SOLID）分离，用户界面和业务模型。

综上所述，如果您必须采用UI包装服务的方式，我强烈建议您在XSLT上使用Razor。

XSLT是一个标准，是的。但是XSLT 2.0的支持仍然有限，因此，如果您要提出该论点，则必须使用过时的标准。

XSLT不容易阅读。不是XSLT专家的任何人。当您需要雇用新员工时，您认为谁更容易找到？有人声称自己是XSLT专家还是MVC专家的ASP.NET？

是的，我已经看到XSLT成功使用了，但是仅在MVC for ASP.NET成为可能之前。