Symfony

[Detonador PHP 1]

Galera, estou abrindo este tópico porque estou aprendendo a trabalhar com o framework Symfony e estou achando incrível. Mas ainda sim acabam surgindo algumas dúvidas. Então gostaria de ir soltando elas conforme eu fosse vendo mais conteúdo sobre o assunto.

 

Bom, a minha primeira pergunta é a seguinte:
Como funciona a hierarquia das pastas do Symfony?

 

Eu andei estudando MVC e vi que tem a questão dos Controllers, Models e Views, mas este framework trata as pastas de forma diferente.

 

Por exemplo:
Pra que serve a pasta app?

Pra que serve a pasta bin?

Pra que serve a pasta src?

Pra que serve a pasta vendor?

 

A src eu entendi mais ou menos. Tu instala lá pacotes com os módulos do sistema?

Mas a pasta que me intriga é a vendor. Pra que ela serve?

[Enrico Pereira 299]

O Symfony não é um tipo de Cake ou Rails que tem lá sua pasta model, controller e view baseado quase completamente em convenções. Pelo que vejo você tem um background nesse tipo de framework, então comparações serão mais fáceis para entendimento.

 

A primeira coisa que você tem que pensar é que o Symfony não é um framework MVC. Você pode seguir o MVC que há em outros frameworks, mas não é obrigado.

 

A segunda coisa: linha de comando será sua maior amiga e a pasta bin/ contém os scripts que você poderá usar.

 

A terceira coisa: você precisa aprender o Composer. Além da documentação, há um

.

 

A quarta coisa: o Symfony é baseado em componentes. Os frameworks tipo Cake são um "negócio" que você sai usando e lhe oferece banco de dados, validação, rotas, etc. de uma vez só, de forma não-modular. O Symfony oferece as features através de pacotes, que podem ser instalados, em sua maioria, individualmente. Os pacotes podem ficar na pasta vendor/ (que é criada pelo Composer).

 

A quinta coisa: tudo que é específico para o kernel do Symfony (plugins, módulos de sua aplicação, etc.) são bundles. Bundles ficam na pasta src/ (os seus bundles) e os externos na pasta vendor/ juntamente com os pacotes e bibliotecas de terceiros, sempre instalados com o Composer.

 

A sexta coisa: a sua aplicação nada mais é do que configuração sobre bundles.

 

Isso significa:

 

app/ - configurações, listagem dos bundles instalados, caches.

bin/ - scripts de linha de comando (instalados pelo Composer).

src/ - bundles seus, seguindo a PSR-0 para autoloading.

vendor/ - pacotes, bibliotecas, bundles e tudo que for de terceiros, incluindo os do próprio Symfony (gerado pelo Composer).

[Detonador PHP 1]

Deixa eu ver se entendi mais ou menos a questão das pastas.

App: Serve para realizar configurações do sistema, instalar os pacotes (bundles) e guardar os caches.

Bin: São os scripts de linha de comando que vou usar mais pra frente.

Src: Meus pacotes, seguinte a PSR-0.

Vendor: Bibliotecas externas que instalo para usar no symfony.

 

Mais ou menos isso?

 

Na verdade a pasta Src será a pasta onde eu realmente vou programar, seria isso?
E como ficaria a organização dos meus módulo, por exemplo:
- Usuários

- Funcionários

- Vendas

- Conta

 

Vi que tem uma pasta Controller lá, mas não vi a Model.

 

E finalmente, qual convenção de nomes eu uso?
a maioria das pastas estas coma inicial em maiúscula, e algumas em minúscula.
Que convenção usar?

[Enrico Pereira 299]

Deixa eu ver se entendi mais ou menos a questão das pastas.

 

App: Serve para realizar configurações do sistema, instalar os pacotes (bundles) e guardar os caches.

Bin: São os scripts de linha de comando que vou usar mais pra frente.

Src: Meus pacotes, seguinte a PSR-0.

Vendor: Bibliotecas externas que instalo para usar no symfony.

 

Mais ou menos isso?

 

Na verdade a pasta Src será a pasta onde eu realmente vou programar, seria isso?

 

Exatamente!

 

 

E como ficaria a organização dos meus módulo, por exemplo:

- Usuários

- Funcionários

- Vendas

- Conta

 

Eles serão bundles.

 

Vi que tem uma pasta Controller lá, mas não vi a Model.

 

 

 

 

"Model" é algo abstrato demais para ser totalmente abstraído. Model, como conhecido em outros frameworks, no estilo ActiveRecord é uma violação do SRP. O mais comum é usar Doctrine2 para persistência, filtro, cache e validação.

 

 

E finalmente, qual convenção de nomes eu uso?

a maioria das pastas estas coma inicial em maiúscula, e algumas em minúscula.

Que convenção usar?

 

Há algumas convenções no site do Symfony para os bundles: http://symfony.com/doc/current/cookbook/bundles/best_practices.html

 

Pastas em StudlyCaps: namespaces compatíveis com a PSR-0.

Pastas em minúsculo: outras pastas.

[Bruno Augusto 417]

Algo abstrato demais para ser abstraído. Essa foi ótima. :D

[Detonador PHP 1]

Eu ainda não entendi direito a questão dos meus módulos.

Atualmente trabalhamos assim:
/modulos/usuario/usuario_lista.php

/modulos/usuario/usuario_edita.php

/modulos/usuario/usuario_apaga.php

/modulos/usuario/usuario_cria.php

 

/modulos/funcionario/funcionario_lista.php

/modulos/funcionario/funcionario_edita.php

/modulos/funcionario/funcionario_apaga.php

/modulos/funcionario/funcionario_cria.php

 

Mas como ficariam nos meus pacotes?

 

Lá tem um pacote de exemplo com esta organização:
/Acme/DemoBundle/Controller/

/Acme/DemoBundle/Form/

/Acme/DemoBundle/Resources/

/Acme/DemoBundle/Twig/

 

Será que meu projeto não deveria ficar assim:

/GameIntro/WebSite/Controller/

/GameIntro/WebSite/Resources/Usuario/

/GameIntro/WebSite/Resources/Funcionario/

/GameIntro/WebSite/Resources/Venda/

/GameIntro/WebSite/Resources/Conta/

/GameIntro/WebSite/Twig/

 

Lembrando que:
GameIntro seria o nome da minha empresa, que é o vendor principal

Website seria o nome do projeto, que faz parte do namespace

[Enrico Pereira 299]

WebSite seria sua aplicação como um todo. A ideia é que você separe em módulos, não ter um módulo "monolítico".

 

Resources é onde você coloca documentação, templates e configuração.

 

A não ser que você vá usar alguma extensão para o Twig, a namespace Twig é desnecessária, já que os templates ficam em Resources/views.

 

Recomendo que você veja o quick start oficial: http://symfony.com/doc/current/quick_tour/the_big_picture.html

[Detonador PHP 1]

Na verdade eu estou fazendo o tutorial do Jobeet, não sei se conhecem.
Eu consegui fazer até a parte de rotas, mas como eu arressem sai de um curso de MVC, acabei ficando perdido na questão da hierarquia das pastas;

 

De qualquer forma vou sim fazer este exemplo Enrico.
Ainda sim dei uma boa lida no primeiro link que postou e acho que mais ou menos entendi o que você quis dizer.

 

É que pelo que li, sempre o primeiro vendor é referente ao nome da empresa ou teu nome, pra que seja possível, por exemplo, compartilhar teu projeto com alguém. Por isso que o nome do bundle de exemplo do Symfony é Acme.

 

Então será que o ideal não seria eu criar meu bundle desta forma:
/GameIntro/Website/Usuario/

/GameIntro/Website/Funcionario/

/GameIntro/Website/Conta/

/GameIntro/Website/Venda/

[Enrico Pereira 299]

Você só está errando dois pontos: deve haver apenas dois níveis superiores de namespace (vendor e pacote, no caso pacote é o bundle) e todo bundle deve terminar com a palavra Bundle, ficando:

 

 

/GameIntro/UsuarioBundle/

/GameIntro/FuncionarioBundle/

/GameIntro/ContaBundle/

/GameIntro/VendaBundle/

 

O vendor existe para evitar conflitos. Você pode ter um UserBundle e querer usar um UserBundle de outro para complementar, se não existisse o vendor, haveria um conflito.

 

PS: O bundle default (Acme\DemoBundle) é apenas um exemplo estúpido para mostrar o básico do básico do Symfony2, o correto é remover.

[Detonador PHP 1]

Esta regra de apenas 2 níveis é específica do Symfony ou é baseado em alguma boa prática?

Pergunto isso porque li que você pode ter tantos níveis quantos forem necessários.

 

Por isso fiquei em dúvida.
Na verdade os bundle seriam meus módulos?

Poderia dizer também que os Bundles seriam os acessos as tabelas do banco de dados?

[Enrico Pereira 299]

Esta regra de apenas 2 níveis é específica do Symfony ou é baseado em alguma boa prática?

Pergunto isso porque li que você pode ter tantos níveis quantos forem necessários.

 

Essa é uma regra da PSR-0. Você pode ter quantos subníveis quiser. Mas deve respeitar os dois primeiros (vendor e pacote).

 

 

Por isso fiquei em dúvida.

Na verdade os bundle seriam meus módulos?

Poderia dizer também que os Bundles seriam os acessos as tabelas do banco de dados?

 

Sim. O Symfony2 possui modularidade obrigatória (apesar de você poder mudar isso, o que não é uma coisa boa.

Os bundles são seu código.

[Detonador PHP 1]

Acho que agora peguei a ideia!
Hoje trabalho assim:
/modulos/contaUsuario/Usuario/

/modulos/contaUsuario/dadosConta/

/modulos/contaUsuario/extratoConsumo/

/modulos/contaUsuario/subContas/

 

/modulos/relatorios/diario/

/modulos/relatorios/semanal/

/modulos/relatorios/mensal/

 

Então ficaria mais ou menos assim?
/GameIntro/UsuarioBundle/ (e dentro do Controller eu teria os códigos para as outras área, como dados da conta, extrado de consumo)

/GameIntro/RelatorioBundle/ (dentro do controller teria os códigos para relatório diario, semanal e mensal)

Essa é a ideia?

[Enrico Pereira 299]

Sim, mas não se esqueça que você vai precisar da classe do bundle (GameIntroUsuarioBundle e GameIntroRelatorioBundle). E também que o código é divido: a rota manda para o controller, o controller faz o que quer e manda uma resposta (o que você poderia chamar de view).

[Detonador PHP 1]

É... a parte de rotas ainda não consegui entender, mas estou estudando ela.
Minha primeira dúvida era mesmo em relação a hierarquia das pastas, porque sai de um curso de MVC e não conseguia fazer o link com o Symfony.

 

Mas agora vou fazer os tutoriais e mais pra frente posto mais perguntas! heheheh

[Enrico Pereira 299]

Rotas nada mais são do que mapeamento de URLs.

 

Em minha opinião você não vai conseguir fazer esse link.

[Detonador PHP 1]

Agora já entendi... sei que o MVC do symfony e diferente!
Já tomei consciência.
Agora baseado nos exemplos vou tentar entender um pouco mais sobre a questão da programação e também na questão de rotas.