Estruturas inteligentes de organização de aplicativos PHP?

10

Existem um milhão e uma estrutura de sistema de arquivos que entra na miríade de projetos de código aberto disponíveis. Coisas como módulos, arquivos de idiomas, domínios, bibliotecas de terceiros, migrações, internacionalização, backups e links sys para outras partes do sistema deram origem a muitas abordagens para organizar o sistema de arquivos de um projeto.

Como desenvolvedor PHP, gostaria de saber se algum tipo de padronização está começando a surgir entre os projetos. Com o PSR-0 , finalmente temos um padrão para nomear e carregar arquivos - mas não sei nada sobre o restante dos componentes que compõem o sistema ou como eles podem ser tratados de maneira sã.

Estamos lidando com muito mais do que apenas o MVC, então que exemplos existem de grandes projetos que lidam corretamente com todas essas coisas?

php  project-management  code-organization  file-structure 
— Xeoncross
fonte
3
Como um desenvolvedor companheiro PHP, eu não esperaria sanidade dos componentes PHP
— CamelBlues
2
@CamelBlues Com base nas chances de acaso, algum desenvolvedor de PHP acaba atrapalhando e fazendo algo certo.
— Xeoncross
Não tenho visto tanto quanto à padronização. Até os últimos anos, você teria suas pastas para coisas de front-end (js, css) e, em seguida, incluiria ou libs e, em seguida, modelos ou temas, e era isso. Recentemente, com as estruturas MVC ganhando popularidade, tudo não está claro. Eu diria para não se preocupar com o uso de um padrão por enquanto e apenas mantenha claro o que acontece em seu aplicativo em particular.
— 21411 Jason

Respostas:

3

Não é realmente possível padronizar como os projetos devem ser apresentados, porque "depende".

Se você introduzir uma estrutura padrão, mas parte dela não for relevante para os requisitos que estão sendo desenvolvidos, poderá acabar com um ruído adicional desnecessário. Da mesma forma, se os padrões precisarem trabalhar para uma ampla gama de projetos, eles precisarão incorporar muitos cenários díspares.

Nosso trabalho como desenvolvedores é procurar padrões e práticas recomendadas e aplicá-los à tarefa em questão. Utilizamos nossa experiência e conhecimento para escolher a estrutura correta do sistema de arquivos para o projeto em que estamos trabalhando.

— Fenton
fonte
+1 Como um todo, eu concordo com você, este é certamente um ponto válido. No entanto, se você remover coisas fora da linguagem (pastas de backup, scripts cron / build, ativos estáticos, etc.) e apenas se concentrar na própria linguagem - não acredito que o mesmo argumento possa ser feito. Os idiomas já têm limitações impostas. Descobrir como organizar todas as suas classes e bloqueios de código para que eles façam sentido para cada projeto é um objetivo real e atingível.
— Xeoncross
0

Não parece haver muito esforço de padronização e, para ser sincero, não vejo o benefício. Há apenas uma regra que você deve aderir, que nunca deve ter sob a raiz da documentação coisas que não pertencem a ela (uma precaução básica de segurança).

Fora isso, eu iria apenas com o que faz sentido para o projeto.

Se você estiver usando MVC (por meio de uma estrutura ou ad-hoc), uma estrutura básica com / models, / views e / controllers faz sentido. Mas mesmo se você não estiver, normalmente você tem algum tipo de camada de acesso a dados com classes que são mapeadas para suas entidades de dados; faz sentido ter um diretório para eles; você também costuma ter um monte de classes de lógica de negócios e funções utilitárias; portanto, outro diretório para elas; se você usar um sistema de modelos, os modelos entram em outro diretório; e então você provavelmente deseja um diretório 'bibliotecas', onde coloca todas as bibliotecas de terceiros. (Depois de chegar a esse ponto, você estará praticamente fazendo o MVC).

Se o projeto for realmente grande, provavelmente poderá ser dividido em submódulos funcionais; se os submódulos forem bastante independentes, faz sentido usá-los como seu nível superior, com um diretório adicional para o código comum.

— tdammers
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.