为什么要使用 Velocity/Freemarker/Thymeleaf 等模板引擎进行数据编织答案

【问题标题】：Why dataweave over template engines like Velocity/Freemarker/Thymeleaf为什么要使用 Velocity/Freemarker/Thymeleaf 等模板引擎进行数据编织
【发布时间】：2021-09-09 14:09:03
【问题描述】：

我看到 Dataweave 被广泛采用，我觉得它更像是转换库，就像 Freemarker 或 Velocity。如果 DW 转换逻辑的更改需要更改代码，同样用途的模板引擎首先流行起来将逻辑和代码分开，这样我们就可以更改转换逻辑而无需重新构建/重新打包我们的代码（更多的部署麻烦)。

谁能帮我指出一些为什么人们更喜欢 DW 的原因。

【问题讨论】：

澄清一下，您不需要在应用程序中包含 DW 代码。在某些情况下，执行从数据库、另一个 API 加载它的动态 DW 甚至将 DW 脚本作为 API 请求的一部分来执行是有意义的。
请问您在 Mulesoft 生态系统之外看到哪些应用？

标签： freemarker velocity dataweave

【解决方案1】：

TLDR：如果您正在为静态网站之类的东西寻找模板引擎，DataWeave 绝对不是正确的选择。为工作使用正确的工具。此外，虽然您可以在 Mule 之外使用 DataWeave，但我认为我没有看到有人采用未采用 MuleSoft 的 DataWeave..

需要考虑的一些事情（其中大部分我是在开发 Mule 应用程序的背景下说明的）：

这些模板引擎通常用于输出静态文本。如果您使用它来输出结构化数据而不是 HTML 页面之类的东西..您可能做错了。他们不会返回结构化数据——他们会返回文本。如果您处于流程的最后，并且要将其从 API 或文件中输出回来，我想您没问题.. 但如果您真的希望能够使用该输出，您将不得不将纯文本转换为实际对象......当您最初可以使用 DataWeave 时，在此过程中引入了许多额外的步骤。当您要处理流式传输等事情时，Dataweave 尤其有用，因为您正在处理大型有效负载。 Dataweave 无需任何额外工作即可以流格式理解 JSON、XML 和 CSV（我看到的三种最常见的数据类型），从而非常容易创建高效的应用程序。模板引擎和数据转换语言之间的最大区别在于，一个用于使用结构化数据作为输入输出文本，另一个用于在输入上处理结构化数据并输出您可以继续使用的结构化数据。几乎所有模板引擎文档都在谈论构建网站而不是集成之类的东西，这是有原因的。

正如 Aled 所指出的，DataWeave 引擎内置在 Mule 运行时中。深深的如此。默认情况下，您可以在任何连接器中的任何字段中使用 DataWeave，即使是没有 f(x) 按钮的字段 - 因为它内置在运行时中。这使得 DataWeave 成为 Mule 中的一等公民，不像您只能通过连接器或调用 java 桥接器/库来使用的东西。您可以通过 DataWeave 或一系列连接器操作来使用。

您列出的好处也不是 DataWeave 无法做到的。您可以非常轻松地模板化和外部化 DataWeave - 例如，我的 maven 存储库中有几个 DataWeave 库，我可以将其作为依赖项包含在内。我已经构建了几个使用 DataWeave 数据库进行转换的转换服务，允许我在不修改应用程序的情况下更改这些转换。您还可以使用动态 DataWeave，在其中使用模板系统在运行之前加载脚本的特定部分。我什至更进一步，编写了一个通用的 DataWeave 脚本，无需编写 DataWeave 即可使用该脚本进行基本映射 - 这让我可以非常轻松地将 Web UI 包裹起来。

除非您是 MuleSoft 商店，否则我不会在 MuleSoft 之外使用 DataWeave。如果您是 MuleSoft 商店，使用 CLI 运行脚本，就像您使用大多数解释性语言一样，效果相当好 - 特别是因为您可能已经拥有 DataWeave 的内部专业知识。该语言仍然足够小众，除非您已经将它用于 Mule 应用程序，否则我认为使用它没有任何优势。

文档/基本示例：

https://github.com/mulesoft-labs/data-weave-native

https://docs.mulesoft.com/mule-runtime/4.3/parse-template-reference

https://docs.mulesoft.com/mule-runtime/4.3/dataweave-create-module

https://github.com/mikeacjones/transform-system-api

【讨论】：

【解决方案2】：

因为它是嵌入在 Mule 运行时的表达式和转换语言。如果您使用 Mule，它还与 IDE Anypoint Studio 集成。

在 Mule 应用程序之外我认为您不能轻松地使用 DataWeave。您可能想选择替代方案。

【讨论】：

同意，但我可以在 Mule 中使用这些模板作为 Dataweave 的替代品，并且可以完成我的转换，而无需重新部署我的应用程序。 DW 提供哪些额外好处
与 IDE 的集成为您提供了图形设计器和预览。与运行时集成意味着 Mule 4 中的每个表达式都是一个 DataWeave 表达式。而且您无需添加库或代码即可调用外部库。我认为这些是 DataWeave 的优势。您必须决定什么更适合您的特定需求，这可能与其他需求不同。
@darshankamat 问题是.. 你不能在 mule 内部使用那些原生的作为 dataweave 的替代品。您将不得不使用某种桥接器，这会使应用程序更难使用。从长远来看，在 MuleSoft 应用程序中使用 dataweave 会更容易且更易于维护。
我认为这个问题纯粹与转换有关，而不是替换核心表达语言。
确实如此，但是像 Freemarker 这样的工具实际上是一个文本模板引擎。它并不意味着输出结构化数据之类的东西，而这是转换语言应该做的事情。此外，在 Mule 中，您仍然需要将文本处理成结构化对象。在 Mule 应用程序中，猜猜会发生什么？所以你添加了很多额外的步骤..特别是因为据我所知，MuleSoft 没有任何官方连接器。重复一遍..这些引擎非常适合输出静态文本之类的东西，比如 HTML...不是您打算使用的结构化数据。