16

我正在构建一个 PHP Web 应用程序，它应该为用户提供在他和另一个人/组织之间订购（ConnectDirect 或文件传输网关）连接的“安装”/设置的可能性。

（连接实现的技术规格并不重要——在应用程序中，它只是关于连接作为产品，可以订购和管理。）

其模型层的类层次结构应代表以下现实世界的基础设施：

  • 有连接，可以订购。
  • 连接可以是 IBM Connect:Direct 连接或 IBM File Transfer Gateway 连接。
  • CD连接直接从 A（源）到 B（目标）。
  • FTGW连接在物理上由两个连接组成：A（源）到 FTGW 服务器和从 FTGW 服务器到 B（目标）——但逻辑上（对于订购用户）它也是一个连接。
  • （另外还有一个 FTGW 连接的情况，它使用 Connect:Direct 作为 protokoll。）
  • 每个端点要么是源，要么是目标。

所以我看到以下逻辑元素：逻辑连接、物理连接、角色（源和目标）、连接类型、顺序、端点、端点类型（CD 和 FTGW）。

我目前拥有的结构如下所示：

连接和端点伪 UML 类图

但它存在一些问题：

  1. 有两个层次结构树，其中一个的每个元素都包含另一个特定子集的元素（每个 CD 连接由 CD 端点组成；每个 FTGW 连接由两个 FTGW 端点组成，或者更准确地说：每个 FTGW 逻辑连接由两个物理 FTGW 连接——每个连接都包含一个 FTGW 端点和作为第二个端点的 FTGW 服务器）。

    另一种方法可能是用两个关系替换 betweetEndpoint和PsysicalConnection的关系：EndpointCD-PsysicalConnectionCD和EndpointFTGW-PsysicalConnectionFTGW。

替换关系

临：更一致；消除了从一对任意端点构建每个连接（类型）的伪造可能性的逻辑不精确性（甚至可能是错误）。相反：实际上，包含两个端点的要求是每个心理连接的一个特征——从这个角度来看，这个正确的地方是非常基本的PsysicalConnection类。

  1. 每个端点都可以是源和目标，不仅包含公共端点属性，还包含源和目标属性。这意味着，取决于端点的当前角色，某些属性是浪费的。这也会影响数据库结构（列，有时必须设置，有时必须 bi NULL）。

    另一种方法是扩展层次结构......

    一个。...通过类EndpointSource和EndpoitTarget直接从Endpoint类继承并被类继承EndpointCD和EndpointFTGW（这意味着：两个相同的子树——在EndpointSource和下EndpointTarget）；

    湾。...通过类EndpointCDSource和EndpointCDTarget（从类继承EndpointCD）和EndpointFTGWSource 和EndpointFTGWTarget（从类EndpointFTGW继承）分别由具体的 CD 或 FTGW 端点类继承（这意味着：两个相同的子树）；

    C。...通过类MyConcreteEndpoint***Source和MyConcreteEndpoint***Target从具体端点类继承（这意味着：每个MyConcreteEndpoint类都变为抽象并获得两个子类—— MyConcreteEndpoint***Sourceand MyConcreteEndpoint***Target, egEndpointCDLinux现在是抽象的并且由EndpointCDLinuxSourceand继承EndpointCDLinuxTarget）。

    优点：消除了浪费的属性。魂斗罗：一个（更）复杂的类层次结构。

嗯，它是关于软件架构的，应该（当然也会）是我的设计决定。但是很高兴听到/阅读一些专家（或非专家）的想法，如何处理这种情况。像我描述的那样，为基础设施组织逻辑项的正确方法是什么？

4

1 回答 1

1

也许我想多了，但我建议您使用稍微不同的模型来反映您的业务逻辑。

以下可能是一个完全的误解，但我会试一试。

所以：

基于实际上任何连接是什么，这里有一个概念：

  • 每个连接都是节点的集合，数据应该经过这些节点才能到达目的地。
  • 每个节点都可以使用特定的协议与下一个节点连接，该协议仅适用于两个特定节点之间的直接连接。
  • 协议有自己的源节点和目标节点共有的属性

基于此，我建议采用以下模型来构建、管理和存储产品配置：

在此处输入图像描述

这里：

  • LogicalConnection 是对实际连接、节点和协议类的构建组合的参考

  • Connection 包含一个节点的双链表，这些节点按数据流的顺序组成。即：第一个元素是源节点，第二个是它的目标，依此类推。

  • 具体节点包含平台特定配置、对目标 (*Node)、源节点 (*Node) 和具体协议 (*Protocol) 的引用

  • Protocol 包含其对 source 和 target 的具体配置，Node 实例可以参考 Protocol 实例来提取所需的配置。

  • 目标和源节点通过双链表结构“看到”彼此和源-目标协议配置。

  • Configurations\*ConfigBuilder 实现编排了从 UI 接受数据并将其转换为连接、节点和协议的实际组合的过程，具体取决于具体情况。

  • IBM\ConnectDirect\ 和 IBM\FTGW\ 命名空间包含 Protocol 和 *Node 的具体实现（例如 WindowsNode、UnixNode）

如果节点或协议仍然需要包含源和目标相关属性，并且在某些配置中它们的一部分仍然可能为 NULL - 如果对未使用的列等有任何顾虑，我建议对 DB 使用 EAV 存储模型。

使用您在问题中描述的建议模型连接可以表示如下：

Connection:IBM_CD {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      protocol:{//IBM.ConnectDirect.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//WindowsShareNode
      target:*nil,
      protocol:{
        //IBM.ConnectDirect.Protocol(same instance or null)
      }
      ..platform specific attributes..
    },
  ]
}

Connection:IBM_FTGW {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      source:*nil,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//IntermediateServerLinuxNode
      target:*nextElement,
      source:*prevElement,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      },
      ..platform specific attributes
    },
    {//WindowsShareNode
      target:*nil,
      source:*prevElement,
      protocol:*nil,
      ..platform specific attributes..
    }
  ]
}
于 2016-04-19T01:36:03.757 回答