建议通用服务的体系结构模式

本文关键字：结构模式 服务 | 更新日期: 2023-09-27 18:10:33

我们正在连接到描述一些Stock Tase信息的不同服务。目前有三种服务。每个服务以不同的方式返回信息:XML、Json、管道分隔字符串。服务的数量在不久的将来会增长。

我想实现这个最灵活的方式，最大的抽象。唯一的模式(从我所熟悉的模式中)是工厂模式或抽象工厂。也许策略模式在这里也是一种选择。

也许你能提出更好的实现方法?

概要:

StockInformationParser 
-> Connects to Service 1 || Service 2 || or Service N 
-> Parses and analyses information
-> returns StockInformationInfo.

建议通用服务的体系结构模式

我假设所有这些外部服务最终都映射到同一个域模型。

在这种情况下，你可以:

  • 创建一个内部服务，其操作可以被客户端使用，并为这些客户端优化数据契约。
  • 内部服务使用底层存储库和域模型。
  • 存储库负责抽象数据的检索方式。在内部，它们从外部提供程序获取数据，并将这些数据映射到您的域对象。您可以为每个外部服务编写提供者，并在存储库中使用它们。如果添加了外部服务，您只需要添加一个新的提供者并将其添加到存储库逻辑中。

我个人喜欢IoC，所以我会为每个组件创建接口并注入具体实例;

针对你的情况，我建议你应用更多的设计模式，并结合起来解决你的问题，如下:1. Facade模式:它作为一个接触点类，在连接多个服务时降低复杂性。

  1. 对于每个结果返回每个服务，您可能需要使用相同方法的解析引擎，但每种格式Json, Xml, rss，…相同的方法，但格式不同，所以你应该应用策略模式来解析。

  2. 每个服务都需要一个方案工厂来连接，所以抽象工厂或工厂设计模式是合适的。

  3. 最后一件事，你会想要的结果是抽象，便于更改或扩展，你可以在这里应用代理模式

我会有一点不同的方法。如何创建一个数据库，并填满这些服务，然后你可以很容易地在喜欢的SQL查询数据库，并使用Group By, Order和Joins。

优势,

  • 不需要重新发明查询适配器，毕竟您需要查询。
  • 无需担心不同的格式，一旦获取的数据保持为行在数据库中。
    • 在服务失败或连接问题的情况下，您仍然可以看到过去的数据。
相关文章：