+9
Organização de Arquivos e Código Fonte para um Sistema Web (Parte 1)
1) Ordem e localização dos arquivos
Um dos itens mais importantes é onde colocar todos os arquivos. Pois afinal de contas, o sistema é basicamente um aglomerado de arquivos!
Estrutura das pastas:
nome_do_projeto/
|--- doc/
|--- layout/
|--- sql/
|--- www/
|-------- cache/
|-------- galeria/
|-------- lib/
|-------- modulos/
|-------- templates/
+ A pasta raiz é de o nome identificador do seu projeto. Eu sempre uso nome da empresa cliente, exemplo: petrobras/.
+ doc é a pasta que contém todos os documentos relacionados ao projeto: contrato, anotações de idéias, propostas, leiame com as configurações para que o sistema funcione corretamente, etc.
+ layout é a pasta que contém o layout "cru", pronto para ser desmontado em html e jogado na programação. Contém também os arquivos de edição originais, exemplo arquivos de photoshop.
+ sql contém os .sql com a estrutura do banco de dados e também dumps de backup.
+ www onde fica o principal: códigos, layout montado, bibliotecas, galeria, etc:
+ www/galeria - fotos dos itens do sistema. Exemplo: numa loja virtual, há as fotos dos produtos, então dentro da galeria tem mais uma pasta chamada produtos que por sua vez contém as fotos dos produtos.
+ www/lib - todas as classes de framework e funcionalidades em geral ficam aqui armazenadas.
+ www/modulos - classes das seções do sistema (módulos).
+ www/templates - toda a parte estética fica armazenada aqui. Normalmente contém as pastas:
css, imagens, flash e js. São auto-explicativas.
Um dos itens mais importantes é onde colocar todos os arquivos. Pois afinal de contas, o sistema é basicamente um aglomerado de arquivos!
Estrutura das pastas:
nome_do_projeto/
|--- doc/
|--- layout/
|--- sql/
|--- www/
|-------- cache/
|-------- galeria/
|-------- lib/
|-------- modulos/
|-------- templates/
+ A pasta raiz é de o nome identificador do seu projeto. Eu sempre uso nome da empresa cliente, exemplo: petrobras/.
+ doc é a pasta que contém todos os documentos relacionados ao projeto: contrato, anotações de idéias, propostas, leiame com as configurações para que o sistema funcione corretamente, etc.
+ layout é a pasta que contém o layout "cru", pronto para ser desmontado em html e jogado na programação. Contém também os arquivos de edição originais, exemplo arquivos de photoshop.
+ sql contém os .sql com a estrutura do banco de dados e também dumps de backup.
+ www onde fica o principal: códigos, layout montado, bibliotecas, galeria, etc:
+ www/galeria - fotos dos itens do sistema. Exemplo: numa loja virtual, há as fotos dos produtos, então dentro da galeria tem mais uma pasta chamada produtos que por sua vez contém as fotos dos produtos.
+ www/lib - todas as classes de framework e funcionalidades em geral ficam aqui armazenadas.
+ www/modulos - classes das seções do sistema (módulos).
+ www/templates - toda a parte estética fica armazenada aqui. Normalmente contém as pastas:
css, imagens, flash e js. São auto-explicativas.
O que mais me interessou sim foi a nomenclatura dos arquivos... meus sistemas estão crescendo e já estou começando a me confundir!
Parabéns pelo Artigo!
abraços
Parabéns pelo Artigo!
abraços
13/09/2006 4:19am
(~18 anos atrás)
Parabéns pelo ótimo artigo.
Além do padrão Pear também há o padrão de codificação proposto para o Zend Framework.
O link para a documentação em português é http://framework.zend.com/manual/pt-br/coding-standard.html
Abraços.
Além do padrão Pear também há o padrão de codificação proposto para o Zend Framework.
O link para a documentação em português é http://framework.zend.com/manual/pt-br/coding-standard.html
Abraços.
25/08/2006 3:33pm
(~18 anos atrás)
Muito bom artigo, álias, como vc controla versão dos arquivos que vc vai validando??
Abs
Abs
17/07/2006 5:08am
(~18 anos atrás)
Alfred... bom trabalho... principalmente com relação a organização dos arquivos fisicamente. Geralmente, cada pessoa tem sua maneira de organizar, mas um padrão ajuda muito pra universalizar.
Atualmente eu uso o PHPDoc que vc recomendou. Porém, com relação a nomemclatura de clases, métodos... prefiro manter o padrão Java.
Na verdade, com a solução PHPDoc + nomenclatura java no final, toda documentação e organização fica padrão Java! Assim é muito bom pq você adota um padrão de reconhecimento mundial!!
To com a idéia de publicar 2 artigos para complementar seu artigo Alfred (sua ajuda seria preciosa... rsrsrsr). Um citando as metodologias para engenharia do sistema/sw como notação UML, RUP, MR e MER e um sobre controle de versões no PHP (esse eu quero muito estudar... dai divulgo meus resultados).
Caso exista algo pronto aqui sobre isto.... seria bom conferir.
Atualmente eu uso o PHPDoc que vc recomendou. Porém, com relação a nomemclatura de clases, métodos... prefiro manter o padrão Java.
Na verdade, com a solução PHPDoc + nomenclatura java no final, toda documentação e organização fica padrão Java! Assim é muito bom pq você adota um padrão de reconhecimento mundial!!
To com a idéia de publicar 2 artigos para complementar seu artigo Alfred (sua ajuda seria preciosa... rsrsrsr). Um citando as metodologias para engenharia do sistema/sw como notação UML, RUP, MR e MER e um sobre controle de versões no PHP (esse eu quero muito estudar... dai divulgo meus resultados).
Caso exista algo pronto aqui sobre isto.... seria bom conferir.
24/06/2006 6:10am
(~18 anos atrás)
Olá amigo !
Seu artigo é bem simples, porém, muito util !
A dica do PhpDocumentor foi também muito boa ! Trata-se realmente de uma ferramenta facilitadora para nós programadores !
Parabéns !
<a href="http://www.virtuacenter.com.br/tiago">Tiago Gouvêa</a>
Seu artigo é bem simples, porém, muito util !
A dica do PhpDocumentor foi também muito boa ! Trata-se realmente de uma ferramenta facilitadora para nós programadores !
Parabéns !
<a href="http://www.virtuacenter.com.br/tiago">Tiago Gouvêa</a>
01/06/2006 7:44pm
(~18 anos atrás)
Muito bom este artigo!
Server de base para muitas outras organizações, uma vez que cada um tem a sua maneira de organizar seus códigos, mas sempre devem estar baseado (obedecendo)uma regra, e este está correto e simples, agora estou esperando a continuação do artigo, manda ver aí....
Inté + V.
Server de base para muitas outras organizações, uma vez que cada um tem a sua maneira de organizar seus códigos, mas sempre devem estar baseado (obedecendo)uma regra, e este está correto e simples, agora estou esperando a continuação do artigo, manda ver aí....
Inté + V.
09/05/2006 4:09pm
(~18 anos atrás)
Sua solução tem propósito, no entanto acho meio confuso criar toda uma nomenclatura só pra se saber o que o arquivo faz.
apps/
..../cadastros/
......../funcionario/
............/template/
................lista.tpl
................formulario.tpl
............/acao/
................listar.php
................inserir.php
................apagar.php
................atualizar.php
................editar.php
............index.php
css/
doc/
kernel/
image/
include/
js/
smarty/ (dentro além de classes do smarty vão templates globais)
sql/
config.php
define.php
Árvores variam mesmo de acordo com o gosto, no entanto quando se trata de gereciamento de operações dentro do módulo eu controlo através do index.php desviando o fluxo para a ação desejada.
Exemplo:
define('EDITAR',1);
define('XXXXXX',N); // "XXXXXX" nome da operação, "N" id da identificação
switch($op) {
case EDITAR: require 'acao/listar'; break;
case INSERIR: <instruções> break;
case ATUALIZAR: <instruções> break;
case APAGAR: <instruções> break;
default:
require 'acao/listar';
}
Não sei se é um bom exemplo, mas por enquanto tenho adotado esta maneira de trabalhar.
apps/
..../cadastros/
......../funcionario/
............/template/
................lista.tpl
................formulario.tpl
............/acao/
................listar.php
................inserir.php
................apagar.php
................atualizar.php
................editar.php
............index.php
css/
doc/
kernel/
image/
include/
js/
smarty/ (dentro além de classes do smarty vão templates globais)
sql/
config.php
define.php
Árvores variam mesmo de acordo com o gosto, no entanto quando se trata de gereciamento de operações dentro do módulo eu controlo através do index.php desviando o fluxo para a ação desejada.
Exemplo:
define('EDITAR',1);
define('XXXXXX',N); // "XXXXXX" nome da operação, "N" id da identificação
switch($op) {
case EDITAR: require 'acao/listar'; break;
case INSERIR: <instruções> break;
case ATUALIZAR: <instruções> break;
case APAGAR: <instruções> break;
default:
require 'acao/listar';
}
Não sei se é um bom exemplo, mas por enquanto tenho adotado esta maneira de trabalhar.
19/04/2006 9:16am
(~18 anos atrás)
Nota 10.
Como sempre nos surpreendendo em, venho a companhando seu trabalho a algum tempo, e em cada artigo, tenho aprendido mais.
Já apliquei este tipo de organização no sistema que estou desenvolvento, e facilitou bastante para trabalhar com os links de um arquivo para outro, eu criei uns script para fazer a verificação dos links de todos os arquivos, pois utilizo um unico arquivo contendo os links principais e o incluo nos outros arquivos do sistema, seguindo o seu esquema de organização os meu script de tratamento de links ficaram melhor organizados, estou fazendo a ultima verificação nos meus scripts para estar divulgando aqui pra galera.
Vi o Herbert Araujo comentando sobre a nomenclatura dos arquivos comuns. Talvez isso pode ajudar, a nomenclatura que adotei é a seguinte:
Arquivos: sis_frm_ins_user.php | sis_prg_ins_user.php | sis_insert_user.php
Onde:
-"sis" é a identificação do sistema;
-("frm" identifico que este arquivo é o formulário de cadastro;
-"prg" é o script que faz a validação dos campos vindos do fomulário);
-"ins" identifica o que este script ira fazer, neste caso inserir a informação no banco de dados;
-"user" identifica que tipo de informação será inclusa no banco;
-"insert" é o script que faz a inclusão no banco após satisfeitas todas as validação no script anterior {"prg"}.
Utilizo este mesmo esquema para as ações delete "del", update "upd" e pesquisa "sch". Caso esta não seja a melhor maniera aceito sugestões.
É isso ai continue com este excelente trabalho, sucessos.
Como sempre nos surpreendendo em, venho a companhando seu trabalho a algum tempo, e em cada artigo, tenho aprendido mais.
Já apliquei este tipo de organização no sistema que estou desenvolvento, e facilitou bastante para trabalhar com os links de um arquivo para outro, eu criei uns script para fazer a verificação dos links de todos os arquivos, pois utilizo um unico arquivo contendo os links principais e o incluo nos outros arquivos do sistema, seguindo o seu esquema de organização os meu script de tratamento de links ficaram melhor organizados, estou fazendo a ultima verificação nos meus scripts para estar divulgando aqui pra galera.
Vi o Herbert Araujo comentando sobre a nomenclatura dos arquivos comuns. Talvez isso pode ajudar, a nomenclatura que adotei é a seguinte:
Arquivos: sis_frm_ins_user.php | sis_prg_ins_user.php | sis_insert_user.php
Onde:
-"sis" é a identificação do sistema;
-("frm" identifico que este arquivo é o formulário de cadastro;
-"prg" é o script que faz a validação dos campos vindos do fomulário);
-"ins" identifica o que este script ira fazer, neste caso inserir a informação no banco de dados;
-"user" identifica que tipo de informação será inclusa no banco;
-"insert" é o script que faz a inclusão no banco após satisfeitas todas as validação no script anterior {"prg"}.
Utilizo este mesmo esquema para as ações delete "del", update "upd" e pesquisa "sch". Caso esta não seja a melhor maniera aceito sugestões.
É isso ai continue com este excelente trabalho, sucessos.
10/04/2006 8:36am
(~18 anos atrás)
Abraços