É possível acoplar um aplicativo ao seu framework?

14

Digamos que eu esteja desenvolvendo um aplicativo da web. Minha primeira escolha é usar PHP com Fat-Free Framework (F3) e padrão MVC. No ano que vem, posso decidir que quero mudar para o Zend Framework, ou talvez até para o ASP.NET MVC. Faz sentido tentar projetar meu aplicativo de forma que ele seja fracamente acoplado ao seu framework, ou o framework também é parte integrante para tornar isso realista?

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

    
por David Kennedy 09.01.2014 / 01:36
fonte

4 respostas

29

Acoplar livremente seu aplicativo ao framework significa essencialmente que você irá escrever um framework de proxy. Escrever esse framework proxy é muito trabalhoso, e se você mudar para um novo framework, você terá que trabalhar muito para fazer o framework proxy suportar o novo framework. É claro que frameworks diferentes usam idiomas e padrões diferentes, o que tornará o framework proxy muito complexo (se você tentar adequá-lo a tudo) ou muito limitado (se você optar pelo menor denominador comum). De qualquer forma, você terá que lutar com essa estrutura de proxy.

Está tendo a capacidade de mudar os frameworks por um capricho que vale todo esse problema? Como eu disse, você não será capaz de alterá-lo por um capricho porque terá que ajustar a estrutura do proxy, o que pode ser mais trabalhoso do que ajustar o código do aplicativo diretamente.

    
por 09.01.2014 / 01:54
fonte
5

Não pode fazer.

Você pode projetar de maneira que seja portátil em estruturas. O MVC é MVC e os princípios são praticamente os mesmos, independentemente da linguagem ou plataforma utilizada.

O código atual, no entanto, será muito dependente de framework ou idioma. A única maneira de se abstrair disso seria codificar com base em uma estrutura intermediária. Então você pode ter a mudança de implementação intermediária (de F3 para .NET?) Sem alterar o aplicativo. O que é muito trabalho, pressupõe abstrações não permeáveis e apenas move o problema sem resolvê-lo: você está agora preso ao seu framework intermediário.

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

    
por 09.01.2014 / 01:50
fonte
5
Uma vez eu vi Robert C. Martin dar uma palestra onde ele disse algo ao longo das linhas de "a primeira decisão que você toma é a mais difícil de mudar depois".

Então, meu conselho é tentar atrasar essa decisão se você não tiver certeza do que deseja usar ainda. Identifique peças que você pode definir agora e que seriam facilmente independentes de qualquer estrutura que você usasse.

    
por 09.01.2014 / 03:42
fonte
5

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

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

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

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

    
por 09.01.2014 / 12:03
fonte