如果成员也是按层次结构构建的,那么如何构建类结构？

Question

我正在构建一个PHP Web应用程序,它应该为用户提供在他和另一个人/组织之间订购(ConnectDirect或File Transfer Gateway)连接的"安装"/设置的可能性.

(连接实现的技术细节并不重要 - 在应用程序中,它只是作为产品的连接,可以订购和管理.)

其模型层的类层次结构应代表以下实际基础结构:

• 有连接,可以订购.
• 连接可以是IBM Connect:Direct连接或IBM File Transfer Gateway连接.
• 甲CD连接是从A(直接源)到B(目标).
• 甲FTGW连接包括物理上的两个连接的:A(源)到FTGW服务器,并从服务器FTGW到B(目标) -但在逻辑上(用于排序的用户)它也是一个连接.
• (还有一个FTGW连接的情况,它使用Connect:Direct作为protokoll.)
• 每个端点都是源或目标.

所以我看到以下逻辑元素:逻辑连接,物理连接,角色(源和目标),连接类型,顺序,端点,端点类型(CD和FTGW).

我目前的结构如下:

但它有一些问题:

1. 有2种层次结构的树,其中每个元件的一个的由含有特定的元素的子集的其他(各CD连接的由CD端点;每个FTGW连接包括两个FTGW端点,或更正确地:每个FTGW逻辑连接包括两个物理FTGW连接 - 每个连接由一个FTGW端点和FTGW服务器组成,作为第二个端点).

   另一种可能是替代的关系betweet Endpoint并PsysicalConnection通过两个关系:EndpointCD-PsysicalConnectionCD和EndpointFTGW-PsysicalConnectionFTGW.

亲:更一致; 消除了从一对任何端点构建每个连接(类型)的伪造可能性的逻辑不精确(或甚至可能是错误).Contra:实际上,包含两个端点的要求是每个psysical连接的特征 - 从这个角度来看,正确的位置是非常基本的PsysicalConnection类.

2. 每个端点可以既源和目标,并含有不仅常用端点属性,还源和目标性.这意味着,取决于端点的当前作用,一些属性是浪费.这也将影响数据库结构(列,有时必须设置,有时必须bi NULL).

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

   一个....类EndpointSource和类EndpoitTarget直接继承Endpoint和继承类EndpointCD和EndpointFTGW(这意味着:两个相同的子树 - 在under EndpointSource和under下EndpointTarget);

   湾 ...由类,如EndpointCDSource和EndpointCDTarget(从类继承EndpointCD)和EndpointFTGWSource 和EndpointFTGWTarget(来自类继承EndpointFTGW)由混凝土CD或FTGW端点类(这意味着:两次两个相同的子树)被继承每个;

   C....通过类,如MyConcreteEndpoint***Source和MyConcreteEndpoint***Target从具体的端点类继承(这意味着:每一个MyConcreteEndpoint类成为抽象的,增加了两个sublesses - MyConcreteEndpoint***Source和MyConcreteEndpoint***Target,比如EndpointCDLinux现在是抽象的,是继承EndpointCDLinuxSource和EndpointCDLinuxTarget).

   Pro:消除废物特性.Contra:一个(更多)复杂的类层次结构.

嗯,它是关于软件架构的,应该(当然也是)我的设计决定.但是听听/读一些专家(或非专家),如何处理这种情况会很好.如我所描述的那样,为基础架构组织逻辑项的正确方法是什么？

Answer 1

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

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

所以：

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

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

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

这里：

• LogicalConnection 是对实际 Connection、Node 和 Protocol 类的构建组合的引用

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

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

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

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

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

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

如果节点或协议仍然需要包含源和目标相关属性，并且其中一部分在某些配置中仍然可能为 NULL - 如果对未使用的列等有任何担忧，我建议使用 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..
    }
  ]
}