Esta questão está focada em extrair as vantagens e desvantagens do uso de estruturas baseadas na Web : como Cake PHP, Zend, jQuery, ASP.NET). Esta questão é completamente independente da linguagem . Deixe-me começar com a noção de "De pé sobre os ombros de gigantes ".

Vantagens:

• Capacita os desenvolvedores - pegando recursos que anteriormente teriam ocupado centenas de linhas de código e compactando-os em uma chamada de função simples, capacita os desenvolvedores a integrar recursos mais complexos em seus sites.
• Permitir o desenvolvimento mais rápido de aplicativos - isso é muito relevante para pessoas que precisam de sites criados em uma janela muito pequena (alguém tem exemplos disso?)
• Custos mais baixos - permite que os programadores repassem economia ao cliente, gerando uma nova gama de clientes que desejavam um site, mas que antes não podiam arcar com os custos mais altos de desenvolvimento.

Desvantagens:

• Perda de entendimento - confiando nos recursos de uma estrutura, um desenvolvedor corre o risco de perder o entendimento de como as coisas funcionam (por baixo do capô).
• O penhasco da configuração - depois que você vai além da configuração de sua estrutura, sua produtividade diminui imediatamente, pode ser difícil implementar recursos fora de uma configuração de estruturas.
• Linhas de orientação do desenvolvedor - você (o desenvolvedor) precisa fazer as coisas da maneira que o desenvolvedor deseja que você faça.

Eu me pergunto o que as pessoas acham dos meus argumentos e se alguém discorda deles. Além disso, se as pessoas tiverem pontos adicionais, eu ficaria agradecido.

Aqui está a conclusão: pode ser difícil implementar recursos fora de uma configuração de estruturas.

Vamos passar por essa suposição por suposição.

Perda de entendimento - confiando nos recursos de uma estrutura, um desenvolvedor corre o risco de perder o entendimento de como as coisas funcionam (por baixo do capô).

Falso. Você nunca perderá a compreensão de como as coisas funcionam. Estruturas não são mágicas. Eles são apenas códigos úteis que você não precisa escrever sozinho.

Acredite ou não, você cometerá erros usando a estrutura. Você precisará depurar até os níveis mais baixos de HTTP para entender o que você fez de errado.

Você nunca perderá de vista o que está acontecendo sob o capô. A menos, é claro, que sua estrutura seja tão épica e perfeita que você nunca tenha um problema.

O penhasco da configuração - depois que você vai além da configuração de sua estrutura, sua produtividade diminui imediatamente, pode ser difícil implementar recursos fora de uma configuração de estruturas.

Isso faz muito pouco sentido.

Primeiro. Construir sem uma estrutura pode transformar um trabalho trivial em uma grande tarefa de programação que inclui teste de unidade, depuração, diagnóstico, controle de configuração e todo esse trabalho sem valor reinventando coisas que estão na estrutura. Como é essa "produtividade"?

Segundo. Implementar coisas fora da estrutura é sempre muito trabalhoso - ahem - implementar qualquer coisa fora da estrutura é sempre muito trabalho. Não tem nada a ver com o tempo gasto aprendendo e configurando a estrutura. Implementar qualquer coisa fora da estrutura é inerentemente difícil.

Linhas de tramitação do desenvolvedor - você (o desenvolvedor) precisa fazer as coisas da maneira que o desenvolvedor [framework] deseja que você faça.

Corrigir. E isso geralmente é uma coisa boa. Fazer as coisas de maneira consistente é mais valioso do que fazê-las da maneira que preferir. Pode exigir "aprendizado" e "entendimento", mas estes têm valor.

Problemas de segurança - oferecer às pessoas essas ferramentas para desenvolver rapidamente sites com aparência profissional é um risco potencial; as pessoas podem criar rapidamente sites com aparência profissional para empresas fraudulentas.

O que? Isso não tem nada a ver com a estrutura. Fraude é fraude, independentemente das ferramentas utilizadas.

Contras: Eventual possível queda de suporte / perda de popularidade

• Se houver duas estruturas da Web que fazem basicamente a mesma coisa e a sua não vencer, há uma chance de o projeto morrer. Nesta situação, você deve manter a estrutura (código aberto), reescrever o aplicativo ou continuar sem atualizações (código fechado).
• Dependendo da estrutura, você pode ser forçado a atualizar seu aplicativo com o cronograma de lançamento da estrutura. Ficar muito para trás pode torná-lo inelegível para suporte. Sem estrutura, você pode trabalhar de acordo com sua programação. (Isso depende se você precisa / deseja suporte ou não).

Pro: código para os negócios

• As estruturas permitem que você não se preocupe com o trabalho pesado e se concentre no código que agrega valor diretamente aos negócios.
• Às vezes, as atualizações de estrutura que (apenas funcionam) permitem fornecer novos recursos aos seus usuários praticamente "de graça". Especialmente com estruturas que vêm com controles personalizados (como uma grade que a nova versão pode oferecer algum tipo de pesquisa / filtro).

Vantagens

• Tempo de desenvolvimento mais rápido
• Menos bugs
• Desenvolvimento compartilhado mais rápido
• Suporte de biblioteca
• Fácil interação com o banco de dados

Desvantagens

• "Encaixotado" na estrutura
• Frequentemente inflexível quando se deseja estender ou modificar o comportamento principal
• "Erros de desgraça" - erros que surgem da arquitetura principal ou subjacente sem um bom retorno ao local de origem. Um exemplo perfeito são os erros do Spring ao usar o Grails.

Defendo o uso de estruturas para todos os projetos, exceto o mais simples. Se você precisar adicionar um formulário entre em contato conosco a um site HTML existente, poderá usar um arquivo PHP em vez de mudar para uma estrutura.

Algumas coisas que vêm à mente são ...

Vantagens

• Reutilização de código - usando uma estrutura, você está reutilizando o código testado e verdadeiro.
• Rápido desenvolvimento / prototipagem.
• (frequentemente) validação de entrada integrada que pode ser presumida segura (dado que o desenvolvedor a está usando corretamente)

Desvantagens

• Perda de suporte. Aqui vem à mente o Symfony 1.4. Imagino que o Symfony suporte o 1.4 por um bom tempo, mas sabendo que o 2.0 não é compatível com versões anteriores, o 1.4 parece um beco sem saída nos próximos anos.
• A sobrecarga; Ao usar uma estrutura, você está executando milhares de linhas que podem não se aplicar ao seu aplicativo específico, mas se aplicam a outros. Alguns consideram isso uma troca razoável e alguns optam por escrever seu código desde o início para obter desempenho.
• Usando a estrutura errada para suas necessidades específicas. Nem todas as estruturas são criadas igualmente.

Tudo depende da estrutura que você usa.

Se você está usando o ASP.NET, está em desvantagem: na melhor das hipóteses , é uma abstração com vazamento e, na pior das hipóteses, é difícil fazer coisas triviais em outras estruturas que não escondem o fato de que você está trabalhando na web.

O ASP.NET MVC procura corrigir esse problema, e faz muito bem.

Existem estruturas para que possamos gastar mais tempo realizando o trabalho e menos tempo construindo andaimes. A esse respeito, não vejo nenhuma desvantagem, a menos que você realmente queira gastar tempo construindo andaimes.

Eu gostaria de acrescentar alguns pontos.

• Um dos maiores problemas com estruturas que eu acho é que as pessoas param para pensar. Eles só querem usar a estrutura porque é legal ou porque sempre usam a estrutura. Eles não param para pensar se o uso é justificado.
• Licenciamento, as pessoas parecem usar estruturas sem realmente olhar para o licenciamento. Isso pode ter implicações de que eles não estão cientes. Ou pense no que acontece quando a licença muda.
• Utilizando o mesmo tipo de estruturas. Às vezes, podem existir muitas estruturas que realmente fazem a mesma coisa. Como empresa, você faz escolhas educadas e não possui uma estrutura diferente para cada projeto.
• Acompanhar novas versões pode ser um desafio

Ainda acho que colocar um pouco mais de esforço para avaliar estruturas, avaliar licenças, manter uma lista limpa de estruturas por uso e ter uma estratégia de versão inteligente vale a pena quando você considera as vantagens.

Vantagens:

• Quando você usa estruturas de forma consistente, o tempo de aprendizado dos projetos diminui para as pessoas que já trabalharam em seus projetos.
• seu próprio desenvolvimento mais rápido
• seus próprios desenvolvedores capacitados

Falo por experiência pessoal nos últimos 13 anos. Na minha empresa, usamos suportes, depois de uma pequena curva foi ótimo. No meu próximo, usamos uma arquitetura que era principalmente opaca, um pouco mais rígida, mas crescida; poderíamos estendê-la, mas o código principal era apenas jarros. E assim por diante. nos últimos 3 anos, trabalhamos em uma pequena empresa (número de desenvolvedores <30) e eram todos os nossos próprios jsps, servlets e ejbs. Observando nossos múltiplos clientes e a repetição de jsps, em 2012, foi criado um filtro j2ee que imitava 20% dos struts2. Por que não usar stuts 2? Eu gostaria que tivéssemos mas: não conseguimos passar pelo nosso arquiteto-chefe; experiência ou tempo insuficientes.

Por isso, tivemos interceptadores de alguns jsps comuns usados ​​pelo nosso mini framework. Agora, quando tive tempo de ler um livro sobre struts 2, vejo que perdemos tanto!

Usamos alguns ótimos algoritmos, caches e interface do usuário, mas perdemos muitas horas e sobrecarregamos muito código que temos um plano de três anos para se aposentar.