Java中的Saxon:XSLT代码重用

作为我对这个问题的思考模式的延续：

根据Michael Kay对该问题的回答，我最终得到了以下将XSLT应用于文档的代码：

Processor processor = new Processor(false);
StringWriter stringWriter = new StringWriter();
Serializer serializer = new Serializer(stringWriter);
XsltCompiler compiler = processor.newXsltCompiler();
XsltExecutable executable = compiler.compile(new StreamSource(new File(transformLocation)));
XsltTransformer transformer = executable.load();
transformer.setInitialTemplate(new QName("main"));
transformer.setParameter(new QName("filePath"), new XdmAtomicValue("location/of/Test.csv"));
transformer.setDestination(serializer);
transformer.transform();
String transformedDocument = stringWriter.toString().trim();

这段代码使用了Saxon中的s9api（我使用的是9.4版）。它允许我设置初始模板并动态注入要转换的文档的路径，这允许我转换非XML文件（在这种特殊情况下，例如CSV）

然而，这在某种程度上抹杀了我的代码的可重用性

让我解释一下：我有一个

transformDocument（）

方法。最初，在我尝试做一些疯狂的事情，比如转换CSV并只处理XML之前，我的

marshalObjectToDocument（）

和

unmarshalDocumentToObject（）

方法都调用了它（这就是可重用性）

以下是在一个只有XML的世界中两个方向的比较：

unmarshalDocumentToObject（）

• 我从一个包含文档的文件开始
• 我这样做：

  newstreamsource（新文件（documentLocation））

• 此

  StreamSource

  可以作为“源”（

  XsltTransformer.setSource（）

  ）传递给

  transformDocument

  ）

marshalObjectToDocument（）

• 我从某种对象开始
• 这将被编组为一个巨大的XML字符串
• 我这样做：

  newstreamsource（newstringreader（giantStringOfXML））

• 此

  StreamSource

  可以作为“源”（

  XsltTransformer.setSource（）

  ）传递给

  transformDocument

  ）

在案例1（

unmarshalDocumentToObject（）

）中，我有一个文件路径，因此我可以更改

transformDocument（）

，以获取一个文件路径字符串并传递它，以便它可以手动将其插入XSLT参数。这适用于XML和纯文本

在案例2中（

marshalObjectToDocument（）

）我没有文件路径。我有一个对象，它被转换成一个包含其XML表示的巨大字符串。我无法将文件路径字符串传递到

transformDocument（）

，因为我没有文件。现在我不能使用

transformDocument（）

。代码可重用性被破坏

---

我在所有这些方面的目标都是能够以某种方式在代码中以相同的方式处理XML和纯文本文档，并且能够重用我的代码来应用XSLT和XSD，无论我是封送还是反封送。这是一个不切实际的目标吗？我注定要为每种文档类型和方向编写不同的代码吗？或者有人能找到解决方法吗？

这肯定是软件工程的一个标准和基本部分吗？这里有三位代码：希望运行转换的应用程序；XSLT引擎（执行转换）和接口层（提供对XSLT引擎提供的服务的抽象），通常对功能进行子集，以仅提供应用程序所需的内容，并以更简单的形式进行操作。接口层的优点是它降低了转换API的复杂性；缺点是它还降低了功能性。当您的应用程序开始需要更多以前隐藏的功能时，您有很多选择：您可以将功能添加到接口层（最终达到它不再增加价值的程度），或者您可以绕过接口层，以获得应用程序中没有价值的部分

代码的重用取决于识别可在多个地方使用的功能的全局。如果应用程序的不同部分正在做不同的事情，那么它们就很难重用代码。有什么新鲜事吗