| Autor |
Mensagem |
|
|
Thiago Senna wrote:Olá,
esta discussão está ótima!
TriTonE wrote:Segundo alguns textos que li sobre DDD, os factories servem tanto para CRIAR objetos complexos quanto para RECONSTITUIR objetos (por exemplo, objetos carregados do repositório).
Eu entendi diferente. As factories apenas criam objetos novos enquanto é responsabilidade do repository carregar objetos existentes.
Sim, você vai utilizar o repository para carregar um objeto. Quando salvamos objetos no repositório, é comum termos atributos "transientes" (referências para services, repositories etc). Então você acaba tendo que satisfazer as dependências dos objetos carregados dentro do repositório mesmo, como você disse. No entanto, quando criamos novos objetos, TAMBÉM temos que fornecer as dependências.
No caso, faz mais sentido "estender" um pouquinho a responsabilidade dos factories de modo a criar e "remontar" objetos. Dessa forma, seu repositório terá uma referência ao factory que, por sua vez, será utilizado para preencher as dependências necessárias antes de retornar o objeto.
Fazendo desse jeito, teremos a lógica a montagem de objetos (criação e reconstituição) em um único local, o que, ao meu ver, facilita a manutenção.
|
 |
|
|
Segundo alguns textos que li sobre DDD, os factories servem tanto para CRIAR objetos complexos quanto para RECONSTITUIR objetos (por exemplo, objetos carregados do repositório).
Então, seu repositório faz a query utilizando seja lá o que for (jpa, hibernate etc). Seu repositório também terá uma referência a um factory (relativo ao aggregate em questão) e o utilizará para recompor esses objetos antes de repassá-los para a aplicação.
|
|
|
|
paulohbmetal wrote:
TriTonE wrote:Bom.. qual é o problema que as regras estão do lado do servidor? Você pode simplesmente modificar regras de negócio alterando ou trocando o script.
Sei lá, na minha opinião é bem menos porco do que guardar os nomes das classes no banco e chamá-las via reflection. 
Mas eu teria que parar a aplicação para mudar os scripts?!
A Paz!!
Considerando que os scripts são interpretados, basta que você substitua o arquivo no servidor. Não sei te informar com certeza, mas acho que você consegue fazer deploy dos scripts através de hot-deploy. Como os scripts são interpretados, assim que você colocar o script no servidor, a nova regra já estará sendo aplicada nas próximas requisições.
|
|
|
|
Bom.. tá aí minha sugestão...
Dê uma olhada no "Quick Start" do Groovy e veja se ela se adapta ao que você deseja fazer.
http://groovy.codehaus.org/Quick+Start
|
|
|
|
Bom.. qual é o problema que as regras estão do lado do servidor? Você pode simplesmente modificar regras de negócio alterando ou trocando o script.
Sei lá, na minha opinião é bem menos porco do que guardar os nomes das classes no banco e chamá-las via reflection.
|
|
|
|
|
Que tal utilizar linguagens de script? Groovy é uma boa pedida...
|
|
|
|
|
|