Estou construindo um aplicativo Web PHP, que deve fornecer ao usuário a possibilidade de solicitar uma "instalação" / configuração de uma conexão (ConnectDirect ou File Transfer Gateway) entre ele e outra pessoa / organização.

(As especificações técnicas da implementação da conexão não são importantes - no aplicativo, são apenas as conexões como produto, que podem ser solicitadas e gerenciadas.)

A hierarquia de classes para sua camada de modelo deve representar a seguinte infraestrutura do mundo real:

temconexões, isso pode ser solicitado.Uma conexão pode ser uma conexão do IBM Connect: Direct ou uma conexão do IBM File Transfer Gateway.A CD conexão é direta de A (fonte) para B (alvo)A FTGW conexão consistefisicamente de duas conexões: A (origem) para o servidor FTGW e do servidor FTGW para B (destino) - maslogicamente (para o usuário que faz o pedido) também é uma conexão.(Além disso, há um caso de uma conexão FTGW, que usa o Connect: Direct como protocolo de conexão.)Cadaponto final é uma fonte ou um destino.

Então, eu vejo os seguintes elementos lógicos:conexão lógica, conexão física, Função (fonte ealvo),Tipo de conexão, ordem, ponto final, tipo de ponto final (CD e FTGW).

A estrutura que tenho atualmente se parece com isso:

Mas existem alguns problemas com isso:

temduas árvores hierárquicas, onde cadaelemento de umconsiste contém elementos de um determinadosubconjunto do outro (cada conexão de CD consiste em pontos finais de CD; cada conexão FTGW consiste em dois pontos finais FTGW ou mais corretamente: cada conexão lógica FTGW consiste em duas conexões físicas FTGW - e cada uma delas consiste em um ponto final FTGW e no servidor FTGW como segundo ponto final).

Uma alternativa pode ser substituir o relacionamento betweetEndpoint ePsysicalConnection por dois relacionamentos:EndpointCD-PsysicalConnectionCD eEndpointFTGW-PsysicalConnectionFTGW.

Pró: Mais consistente; elimina a imprecisão lógica (ou talvez atéerro) da possibilidade falsa de criar todas as conexões (tipo) a partir de um par de quaisquer pontos de extremidade.Contra: Na verdade, o requisito de conter dois pontos de extremidade é uma característica de todas as conexões psíquicas - deste ponto de vista, o lugar certo para isso é o mais básicoPsysicalConnection classe.

Cadaponto final pode serambos fonte e destino econtém não apenas as propriedades comuns do terminal, mas tambémpropriedades de origem e destino. Isso significa que, dependendo da função atual do terminal, algumas propriedades sãodesperdício. E isso também influenciará a estrutura do banco de dados (colunas, queas vezes tem que ser definido eas vezes tem que biNULL)

Uma alternativa é estender a hierarquia ...

uma. ... por classes comoEndpointSource eEndpoitTarget herdando diretamente doEndpoint e sendo herdado pelas classesEndpointCD eEndpointFTGW (isso significa: duas subárvores idênticas - sobEndpointSource e abaixoEndpointTarget);

b. ... por classes comoEndpointCDSource eEndpointCDTarget (herdando da classeEndpointCD) eEndpointFTGWSource eEndpointFTGWTarget (herdando da classeEndpointFTGW) sendo herdados cada uma das classes de terminais concretas CD ou FTGW (que significa: duas vezes duas subárvores idênticas);

c. ... por classes comoMyConcreteEndpoint***Source eMyConcreteEndpoint***Target herdar das classes concretas do terminal (que significa: todos osMyConcreteEndpoint classe torna-se abstrata e obtém dois subtítulos -MyConcreteEndpoint***Source eMyConcreteEndpoint***Target, por exemplo.EndpointCDLinux agora é abstrato e é herdado porEndpointCDLinuxSource eEndpointCDLinuxTarget)

Pró: elimina as propriedades de resíduos.Contra: Uma hierarquia de classes (mais) complexa.

Bem, é sobre arquitetura de software e deve (e é claro) ser minha decisão de design. Mas seria bom ouvir / ler alguns pensamentos de especialistas (ou não especialistas) sobre como lidar com esse caso. Quais são as maneiras adequadas de organizar os itens lógicos para uma infraestrutura como o que descrevi?