我有一个通过 API 调用收到的整合产品 xml。XML 包含 P1、P2、P3 等各种产品的数据。 我需要编写一个 Windows 服务，我将在其中进行此 API 调用，解析 xml，然后将其分解为三个单独的 xmls..即每个产品 P1、P2、P3....等一个。 每种产品解析 xml 的业务规则可能不同。
将来，我可能需要将相同的输入 xml 分解为新的附加产品 P4、P5 等。
我可以想到策略设计模式来解决这个问题，以便代码可维护，更易于测试和将来可扩展。 请问这是在这里应用的正确模式吗？
谢谢。
【问题讨论】：
标签： c# design-patterns
不要过早地应用任何设计模式。
编写最直接有效且易于阅读的代码。
当未来出现需求时，您可以返回并重新访问代码。只要它以清晰直接的方式编写，就很容易看出可用于清理代码并使其更易于阅读的常见模式是什么。
【讨论】：
@hasen 当然，从简单直接的设计开始是有意义的，但从（可能的）好的设计开始会省力。
我觉得责任链 (COR) 可能是满足此类需求的一个很好的模式。我想数据来自（可能是顺序的）xml 解析器。我们将数据（标签）流传递给标签处理程序链，其中链中的每个处理程序都能够处理一种类型的对象（或其中的一部分）。每个标签要么处理它，要么进一步传递它，为其他人提供机会。
这个链是在运行时形成的，它可以灵活地根据新标签和带有额外处理程序的产品进行自我重组，并提供扩展点。
这可能需要一些额外的能力来保持内存由少数（元）标记处理程序处理（可能通过委托）。
虽然我没有想到完整的设计，但 COR 看起来更适合它。
【讨论】：