logo标签列表

在Sitecore中使用XSL与C#相比有什么优势？

xsltsitecoresitecore6
9
在学习Sitecore时，我发现网络上大多数Sitecore示例代码都是用XSL而不是.NET写的。 选择XSL相比作为.NET开发人员熟悉的过程，有什么优势呢？ 使用XSL是否有处理速度方面的优势？ 一旦熟悉语法，XSL是否实际上更容易？
没有使用案例，这种类型的问题（“X相较于Y的优势”）是主观和有争议的。 - user357812
@Alejandro，我再次查看后同意您的观点。对于修改问题有何想法？如果没有，我打算接受@James Walford的答案。 - JoshBaltzell
6个回答
7

我也想说两句:

我发现XSLT存在太多限制，需要通过外部“库”或开发C#方法来克服。

所以我认为使用Asp.Net更简单。但是我对Asp.Net比对XSLT更熟悉。

但XSLT有一些好处:

  • 从当前上下文项获取字段时非常好用
  • 用于处理简单内容等方面很好
  • 不会强制解决方案重启/重新编译
  • 通常失败的方式比较友好，即页面仍然可以工作，但失败的XSLT会提示错误

当我刚开始使用Sitecore时，我们的公司使用了相当多的XSLT，但由于它的限制和大多数人更熟悉Asp.Net/C#，我们已经逐渐放弃了它。

3

由于现有团队技能、XSL人才的可用性或认为XSL更易学习和成本更低，一些人更喜欢使用XSL。

在Sitecore中，基于ASP.NET的子布局实际上比XSL渲染表现更好。如果你熟悉它，请使用它。我自己从未创建过XSL渲染。

3

XSLT是一种强大的语言，与像ASP.NET这样的语言相比，其主要优点在于当您想要在各种不同页面或不同源文档结构上重用和自定义逻辑时，具有共享元素和其他可变结构。为了实现这一目标，它使用基于规则的处理模型，对于初次接触的一些人来说，可能会发现它很难掌握。学习它是一项长期投资，但起步可能有些困难。

至于性能方面，我从未遇到过任何一个网站无法胜任工作的情况，包括一些非常高压力的服务；当人们遇到性能问题时，通常是在处理管道的其他部分（或仅仅是由于糟糕的编码）。

特别针对Sitecore，在某些情况下，由于Sitecore的实现方式，XSLT确实具有性能缺点。XML结构非常通用，这意味着测试节点值而不是名称。节点深度也可能是一个问题，使得递归搜索代价昂贵。在Sitecore实现中没有选择处理器，尽管自定义它可能并不难。最后，它还依赖于C＃中的一些XSLT扩展，这可能有其自身的缺点。 - James Walford
继续...从我在Sitecore中看到的情况来看，.NET通常是添加演示组件的更有效方式，这些组件需要执行比最基本的简单任务更多的操作。此外，还有一些Sitecore XSLT最佳实践（例如使用For each），这些做法与大多数XSLT开发人员的直觉相反。 - James Walford
3
在Sitecore中，选择使用XSLT还是.NET组件很大程度上取决于个人偏好和技能水平。然而，Sitecore中的XSLT确实存在一些缺点——除了最简单的渲染之外，它往往被.NET组件性能所超越。在似乎最合理使用XSLT的地方，例如将内容树结构复制为站点菜单，实际上会对性能造成最严重的影响。在适当的情况下，XSLT是一种非常强大的工具，值得学习，但我还没有看到令人信服的论据，证明在Sitecore中大量使用它是有益的。此外，值得注意的是，XSLT编程的一些标准模式在Sitecore中并不是最有效的。
3
我所能想到的唯一真正的优点是，XSLT呈现更容易独立部署。例如，假设您正在更新“新闻刊登”呈现，并希望立即将此更改部署到测试/生产 - 这只是上传.xsl文件本身的简单情况。
使用.NET开发（并忍受Web应用程序项目模型），代码库的部署会隐式地部署所有受影响的程序集的任何更改，包括您正在进行的所有工作。
当然，有办法来管理这个问题。源代码分支/合并等等 - 但这是解决方案的额外复杂层面。
话虽如此，我自己超过95％的Sitecore开发都使用.NET :-)
3
总的来说，软件设计和编码的主要目标是征服复杂性。许多编程实践背后的动机是为了减少程序的复杂性。减少复杂性是成为有效程序员的关键。-Steve McConnell（1993）
当决定使用XSLT还是C#时，请以此为指导。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接