É possível acoplar um aplicativo livremente à sua estrutura?

Digamos que estou desenvolvendo um aplicativo da web. Minha primeira opção é usar o PHP com o Fat-Free Framework (F3) e o padrão MVC. No próximo ano, posso decidir mudar para o Zend Framework, ou talvez até o ASP.NET MVC. Faz sentido tentar projetar meu aplicativo de forma que ele seja fracamente acoplado à sua estrutura, ou a estrutura é essencial demais para torná-la realista?

A única razão pela qual pergunto é porque surgiu recentemente em uma conversa com um colega, que criticou minha ideia no céu de acoplar livremente meu aplicativo à F3.

O acoplamento frouxo de seu aplicativo à sua estrutura significa essencialmente que você irá escrever uma estrutura de proxy. Escrever essa estrutura de proxy é muito trabalhoso, e se você mudar para uma nova estrutura, precisará fazer muito trabalho para fazer com que a estrutura de proxy suporte a nova estrutura. Obviamente, estruturas diferentes usam expressões e padrões diferentes, o que tornará a estrutura proxy muito complexa (se você tentar ajustá-la a tudo) ou muito limitada (se você optar pelo menor denominador comum). De qualquer maneira, você terá que lutar com essa estrutura de proxy.

Ter a capacidade de alterar estruturas por um capricho vale todo esse problema? Como eu disse, você não poderá alterá-lo por capricho, porque precisará ajustar a estrutura do proxy, o que pode resultar em mais trabalho do que ajustar o código do aplicativo diretamente.

Não pode fazer.

Você pode projetar de uma maneira portátil em todas as estruturas. MVC é MVC, e os princípios são praticamente os mesmos, independentemente do idioma ou plataforma usada.

O código real, no entanto, será muito dependente da estrutura ou da linguagem. A única maneira de se abstrair disso seria codificar com base em uma estrutura intermediária. Em seguida, você pode alterar a implementação intermediária (de F3 para .NET?) Sem alterar o aplicativo. O que dá muito trabalho, assume abstrações sem vazamentos e apenas move o problema sem resolvê-lo: agora você está vinculado à sua estrutura intermediária.

Em uma nota mais positiva: considere expressar alguns de seus testes (estilo BDD) em uma plataforma independente da sua implementação. Eles podem sobreviver a grandes reescritas.

Certa vez, vi Robert C. Martin dando uma palestra em que ele disse algo como "a primeira decisão que você toma é a mais difícil de mudar depois".

Portanto, meu conselho é tentar adiar essa decisão se você ainda não tiver certeza do que deseja usar. Identifique as peças que você pode definir agora e que permaneceriam facilmente independentes de qualquer estrutura que você acabar usando.

O bloqueio da estrutura pode ser um problema sério, mas ajuda a encarar o problema como portabilidade. Portabilidade não é um atributo absoluto, mas relativo ao seu ponto de partida e para onde você pode querer ir. Por analogia, então, o software é portátil apenas na medida em que você já o transportou para outros ambientes.

A maior parte do desenvolvimento de um aplicativo dentro de uma estrutura tende a ser um código de cola, o material que une os componentes da estrutura. Os arquivos de configuração podem abstrair uma certa quantidade de cola em alguns sistemas, mas muitos detalhes são necessários no código.

Por outro lado, regras e processos de negócios podem ser abstraídos do aplicativo. A parte mais difícil da abstração é quando as regras são implementadas diretamente pela estrutura; segurança, acessibilidade e seqüenciamento de processos tendem a ser reforçados por sua estrutura e podem ser os mais difíceis de ver.

Se você pode separar a parte de cola do seu aplicativo da regra de negócios e a parte do processo de negócios e dos dados de negócios, poderá tornar portáteis algumas partes da sua solução.