Estoy creando una aplicación web PHP, que debería proporcionar al usuario la posibilidad de ordenar una "instalación" / configuración de una conexión (ConnectDirect o File Transfer Gateway) entre él y otra persona / organización.

(Las especificaciones técnicas de la implementación de la conexión no son importantes: en la aplicación solo se trata de las conexiones como producto, que se pueden ordenar y administrar).

La jerarquía de clases para su capa de modelo debe representar la siguiente infraestructura del mundo real:

Existenconexiones, eso se puede pedir.Una conexión puede ser una conexión de IBM Connect: Direct o una conexión de IBM File Transfer Gateway.A discos compactos la conexión es directa desde A (fuente) a B (objetivo)A FTGW la conexión consistefísicamente de dos conexiones: A (fuente) al servidor FTGW y del servidor FTGW a B (destino), perológicamente (para el usuario que realiza el pedido) también es una conexión.(También hay un caso de una conexión FTGW, que usa Connect: Direct como protokoll).Cadapunto final es una fuente o un objetivo.

Entonces veo los siguientes elementos lógicos:conexión lógica, conexión física, papel (fuente yobjetivo),tipo de conección, orden, punto final, tipo de punto final (CD y FTGW).

La estructura que tengo actualmente se ve así:

Pero hay algunos problemas con esto:

Existendos árboles de jerarquía, donde cadaelemento del unoconsiste contiene elementos de un particularsubconjunto del otro (cada conexión de CD consta de puntos finales de CD; cada conexión FTGW consta de dos puntos finales FTGW, o más correctamente: cada conexión lógica FTGW consta de dos conexiones físicas FTGW, y cada una de ellas consiste en un punto final FTGW y el servidor FTGW como segundo punto final).

Una alternativa podría ser reemplazar la relación entreEndpoint yPsysicalConnection por dos relaciones:EndpointCD-PsysicalConnectionCD yEndpointFTGW-PsysicalConnectionFTGW.

Pro: Mas consistente; elimina la imprecisión lógica (o tal vez inclusoError) de la posibilidad falsa de construir cada conexión (tipo) desde un par de puntos finales.Contra: En realidad, el requisito de contener dos puntos finales es una característica de cada conexión física: desde este punto de vista, el lugar correcto para esto es el más básicoPsysicalConnection clase.

Cadapunto final puede serambos fuente y destino ycontiene no solo las propiedades de punto final comunes, sino tambiénpropiedades de origen y destino. Eso significa que, dependiendo del rol actual del punto final, algunas propiedades sonresiduos. Y esto también influirá en la estructura de la base de datos (columnas, quea veces tiene que ser configurado ya veces tener que biNULL)

Una alternativa es extender la jerarquía ...

a. ... por clases comoEndpointSource yEndpoitTarget heredando directamente de laEndpoint y ser heredado por las clasesEndpointCD yEndpointFTGW (eso significa: dos subárboles idénticos - bajoEndpointSource Y debajoEndpointTarget);

si. ... por clases comoEndpointCDSource yEndpointCDTarget (heredando de la claseEndpointCD) yEndpointFTGWSource yEndpointFTGWTarget (heredando de la claseEndpointFTGW) siendo heredado cada uno por las clases concretas de punto final CD o FTGW (eso significa: dos veces dos subárboles idénticos);

C. ... por clases comoMyConcreteEndpoint***Source yMyConcreteEndpoint***Target heredar de las clases concretas de punto final (eso significa: cadaMyConcreteEndpoint la clase se vuelve abstracta y obtiene dos subtítulos:MyConcreteEndpoint***Source yMyConcreteEndpoint***Target, p.ej.EndpointCDLinux ahora es abstracto y es heredado porEndpointCDLinuxSource yEndpointCDLinuxTarget)

Pro: elimina las propiedades de desecho.Contra: Una jerarquía de clase (más) compleja.

Bueno, se trata de arquitectura de software y debería (y por supuesto lo será) mi decisión de diseño. Pero sería bueno escuchar / leer a algunos expertos (o no expertos), cómo manejar este caso. ¿Cuáles son las formas adecuadas de organizar los elementos lógicos para una infraestructura como la que describí?