Então galera, sei que existe diversos containers no mercado e já andei lendo alguma coisa aqui mesmo no forum.
Mas a dúvida é a seguinte.
[b]
Supondo o desenvovimento de um sistema, aonde ficou decidido se cria um framework próprio, aonde haveria um (módulo-opcional) para se usar DI.
O que eu faria?
1 - Utilizaria algum container existe para fazer isto .
ou
2 - Criaria o meu container de DI. (Está opção é muito complexa de se desenvolver ?)
caso a opção escolhida fosse a n° 1, qual o melhor container para integrar com o meu framework ??
[/b]
Utilize um existente, claro. Nao ha a menor justificativa para tentar criar um framework caseiro sendo que existem otimas opcoes disponiveis. Alias, porque ficou decidido que no projeto sera feito um framework proprio, ao inves de usar os tantos existentes? Fazer um “em casa” dara muito mais trabalho, ira demorar mais, terao mais coisas para manter e tantos outros problemas.
Rafael,
a idéia de usar um framework “caseiro”, é na verdade projeto de faculdade…
estou cansado dessa galera fazendo sistema de locadora, aluguel de carro entre outros bla bla bla.
Na verdade a ídeia é mais para estudo, fazer algo do tipo Convetion over Configuration entende …
Legal a sua idéia. Eu fiz um container para estudos também (não foi pra faculdade não, foi só porque eu queria entender melhor como funcionava) e não demorei muito pra conseguir bons resultados (pouco menos de um mês para ficar “usável”).
[quote=diguix]Rafael,
a idéia de usar um framework “caseiro”, é na verdade projeto de faculdade…
estou cansado dessa galera fazendo sistema de locadora, aluguel de carro entre outros bla bla bla.
Na verdade a ídeia é mais para estudo, fazer algo do tipo Convetion over Configuration entende …
[/quote]
Fazer um IoC container é trivial e é muito bom para entender reflection.
Se vc pretender usar Annotations tanto melhor. O que não é trivial é fazer um bom IoC. Mas se é para estudo/faculdade é com certeza mais util que um programa de locadora.
A maior parte das coisas é facil fazer. E, como vc disse, fazer direito é outra historia. Logo, para que perder tempo implementando algo que ja existe as centenas?
Quer fazer para estudar? Beleza. Mas fazer para usar em producao é simplesmente sofrer de NIH.
Fazer um IoC container é trivial e é muito bom para entender reflection.
Se vc pretender usar Annotations tanto melhor. O que não é trivial é fazer um bom IoC. Mas se é para estudo/faculdade é com certeza mais util que um programa de locadora.
[/quote]
Então ja andei olhando por ai e tal mas não achei código ou algo do gênero para começar a não ser os fontes de projetos já existentes …
…alguma dica ??
Ele explica exatamente o que é injeção de dependências e dá exemplo de como os principais IoC containers existentes ( Spring, PicoContainer ) funcionam.
A partir daí, fica menos complicado implementar um IoC container simples. Decida a maneira como você vai declarar as classes que o framework instanciará ( XML? Arquivos YAML? Annotations? ) e pronto.
Fazer um IoC container é trivial e é muito bom para entender reflection.
Se vc pretender usar Annotations tanto melhor. O que não é trivial é fazer um bom IoC. Mas se é para estudo/faculdade é com certeza mais util que um programa de locadora.
[/quote]
Então ja andei olhando por ai e tal mas não achei código ou algo do gênero para começar a não ser os fontes de projetos já existentes …
…alguma dica ??
[/quote]
não ha muito a fizer. Os IoC são factories que constroem objetos. No estilo Spring a definição da injeção ( qual objeto é populado com quais outros objetos) fica em um arquivo. No estilo Guice (lê-se juice) são usadas anotações.
O estilo guice é muito mais moderno mas tem o problema - no caso do juice - de ficar amarrado a anotações especificas.
Se por exemplo vc quiser incorporar o guice em outro sistema ou framework vc teria que usar as anotações do juice não sendo possivel encapsulá-lo. Isso vc resolve facilmente criando um mecanismo configuração de quais anotações fazem o quê.
Todo o ponto dos containers é criar objetos. Para isso eles usam a Class e os usam reflection para ler os contrutores. Um deles deve ser anotado para ser chamado. Se ele não tem parametros, otimo. Se tem, o container irá criar esses outros objetos com o mesmo mecanismo e depois chamar o construtor já com esses objetos criados. É facil entender daqui que é o processo é recursivo até que o objeto principal possa ser criado. Isso implica também que pode existir recursividade cíclica, que é algo que não é trivial resolver.
Depois do objeto criado ele pode ser mantido em memoria ou não. Se não, ele será criado de novo da proxima vez.
O esquema de manter em memoria é oferecido pelo Guice de forma configurável. Vc decide onde como o objeto é guardado. O default é criar um novo a cada pedido. O spring cria um so e mantem na memoria interna por padrão.
Estes objetos que são criados e mantidos na memoria são chamados ( erroneamente) de singletons pelos frameworks de injeção.
Por outro lado o container terá dificuldades em criar todos os tipos de objeto. (por exemplo, String é dificil). Ele será obrigado a abdicar da construção de certos tipos ou a delegar essa construção. Aqui o IoC vira uma fabrica que chama outras fábricas.
Na realidade o IoC é apenas isso, um Factory turbinado que cria tudo sozinho… ou quase.