Teria algum problema se o ActiveRecord nesse caso for “jogado” no User por IoC?
Eu nao consigo ver como fazer o controle de transacao se o proprio User criar o seu ActiveRecord.
Como vc falou na segunda resposta o resto do sistema nem deveria saber que o ActiveRecord existe então eu acho que expor métodos de persistencia para essa parte dá informações demais, mas tudo bem.
Referente forçar o constraint neste casos é dificil mesmo em Java.
Vc tem razão. Eu acho que isso falta em java.
Em outro tópico eu postei alguma dúvida sobre isso. Refleti algumas coisas e cheguei em algumas gambiarras.
O esquema seria poder limitar quem pode instanciar uma classe que é publica com construtor publico em outro pacote.
Ou colocar o Active Record no mesmo pacote.
[quote=fabgp2001]Teria algum problema se o ActiveRecord nesse caso for “jogado” no User por IoC?
Eu nao consigo ver como fazer o controle de transacao se o proprio User criar o seu ActiveRecord.[/quote]
Ele nao vai soh criar o ActiveRecord dele - ele eh um ActiveRecord, tambem. O lance que eu usei pra sair dessa eh usar um ThreadLocal pra manter a configuracao. Nesse ThreadLocal vc pode manter a transacao atual, e mais um monte de badulaques uteis. Ainda nao tentei nada tao “generico” desse jeito, mas talvez alguem aih tenha uma ideia de como a coisa deteriora quando se joga 5 milhoes de problemas diferentes em cima.
O lance de nao “mostrar” o ActiveRecord pra ninguem nao eh necessariamente verdade, tambem - se vc quiser injetar o bicho via IoC e deixar pra la a regrinha, tambem vale.
Verdade, nao tinha pensado em centralizar essas badulaques de infra no ThreadLocal. Sobre muito generico eu tambem nao gosto porque vira ninho de cobra pra bugs.
Agora só falta eu pensar numa maneira de tratar a transacao dentro do ThreadLocal sem ficar feio o esquema e jogar todo esforco pelo ralo.
]['s
[quote=cv]
O lance de nao “mostrar” o ActiveRecord pra ninguem nao eh necessariamente verdade, tambem - se vc quiser injetar o bicho via IoC e deixar pra la a regrinha, tambem vale.[/quote]
É mas na tua primeira frase tu quebrou isso, se eu “jogar” por IoC o User nao sera mais o ActiveRecord e passará a usar um, ai o pattern foi pro espaco nao?
É mas na tua primeira frase tu quebrou isso, se eu “jogar” por IoC o User nao sera mais o ActiveRecord e passará a usar um, ai o pattern foi pro espaco nao?[/quote]
Bom, se vc jogar um AR pra ele, ele vai passar a ser E usar um AR. Nao estranhe se comecarem a sair umas bolinhas de sabao dele dentro de alguns meses, e o cheiro eh completamente normal, eu garanto :mrgreen:
Minha cabeça tá dando tilte! Que salada de frutas é esse Java! Acho que se continuar assim, num vai ser Active Record, DAO, DTO, DPCO, DMACTO, Façade, Caçarola, Jabuticaba que vou usar, vai ser o que me der na telha e o que eu (e/ou colegas) pessoalmente achar(em) melhor.
@ Ah, valendo até inventar pattern, ferramenta ou o que seja!
Para não desperdiçar o post com minha inútil opinião:
E se eu quiser reusar a lógica que tem esse Active Record? Mesmo com interfaces e independência de implementação, fazer da persistência uma característica nata da lógica de negócios (aff, podiam inventar uma sigla pra isso), ou seja, mesmo assim, a própria dependência das interfaces, num é ruim?
Normal, a minha ja vem com tilte a tempos. :mrgreen:
E tu nao usa o que tu acha melhor? Como faz me explica ai.
[quote=renato3110]
E se eu quiser reusar a lógica que tem esse Active Record?[/quote]
Primeiro, a logica que tu diz sao os save(), delete(), etc? Se é isso podes fazer como eu sugeri usando IoC pra setar o AR (como fala o CV) ou ainda usar a ThreadLocal pra retornar um objeto de AR mais generico que possa ser usado por varias classes de negocio. Isso é simples e nao doi. Mas nao exagere nas funcionalidades desse AR generico.
Se a logica que tu diz nao for essa, mas sim as que o User implementa, ai temos problemas de OO.
fabgp2001, às vezes o que a gente acha melhor, num futuro próximo ou não pode se mostrar não tão melhor assim, então a gente fica ouvindo conselhos. Só que me parece ter vários jeitos de se fazer as coisas, eu fico meio perdido e pensando agora: será que num seria melhor parar um pouco e pensar com a própria cabeça? Por exemplo, ninguém ainda respondeu minha pergunta, o que me faz pensar que o meu jeito de modelar (um dos milhares possíveIS, isso que é esquisito) num é lá tão ruim.
Sobre o reuso, falo dos métodos de persistência, que não são lógica de negócio, assim como a GUI não é. Deixa eu explicar melhor: imagina que tu faz uma aplicação mais ou menos, que por um acaso precisa de persistência, aí depois surge alguma necessidade (e esse é o ponto: surge?) de você reusar umas classes, mas tu num quer mais persistir, num precisa, num quer ou num pode mais usar AR, sei lá… entende? Um exemplo bobo: imagina uma calculadora que usa AR para persistir, aí um belo dia você quer reusar essa calculadora numa outra situação, mas a “persistibilidade” :shock: do troço num te interessa mais, tipo uma dependência, entende?
Eu acho que esse AR torna a lógica de negócios menos “pura”, entende? Entende? Bom, a não ser que se use herança… Isso tem a ver com uma parada que escrevi um dia desses…
Renato, os patterns e a maioria das metodologias/soluções/mágicas só devem ser usados se você identificar a sua NECESSIDADE. não usar por usar, isso já foi discutido e falado aqui várias vezes …
É importante conhece-los para quando se deparar com um problema vc poder dizer “Ei, peraí! O pattern XYZ resolve isso fácil-fácil” … mas nao procure como modelar sua solução para encaixar algum pattern.
Em geral os patterns são aplicados durante um refactoring e não na primeira implementação.
Por isso faça do seu jeito, quando empacar procure uma solucao para seu problema e refactor nele.
Renato, os patterns e a maioria das metodologias/soluções/mágicas só devem ser usados se você identificar a sua NECESSIDADE. não usar por usar, isso já foi discutido e falado aqui várias vezes …
É importante conhece-los para quando se deparar com um problema vc poder dizer “Ei, peraí! O pattern XYZ resolve isso fácil-fácil” … mas nao procure como modelar sua solução para encaixar algum pattern.
Em geral os patterns são aplicados durante um refactoring e não na primeira implementação.
Por isso faça do seu jeito, quando empacar procure uma solucao para seu problema e refactor nele.[/quote]
No caso o problema é fazer uma estrutura legal que não vá me dar problemas no futuro, mas isso é meio indefinido. Talvez seja isso mesmo, fazer do jeito que der na telha e ficar ouvindo “seu código é porco” aqui e ali, mas não se importar. Num parece tudo muito subjetivo?
Smota, é tipo assim, eu sei que no caso os patterns só devem ser usados quando identificados os problemas, e não apenas porque é elegante. Mas aí é como se eu tivesse perdido entende? Veja: acho que a maneira mais natural seria algo “linear”, que equivaleria a sair escrevendo o que viesse na cabeça, leia-se no meu caso, SQL no JSP! Aí depois de três meses: “ih, esse SQL no JSP tá atrapalhando, vamu tira isso ae vamu” (com o sotaque do Cantuária aqui do trampo hehehehe).
Resumindo, ainda num identifiquei problemas específicos, mas também se sair fazendo de qualquer jeito vou acabar fazendo uns bagulhos muito esquisitos tipo SQL+JSP, Servlet+HTML etc. entende?
cv, essa implementação do active record ficou bem legal. A ideia de compor os AR soluciona um dos problemas que eu tive quando tentava implementar o ActiveRecord usando herança e alguns commands.
Phillip, porque vc não usaria o AR em projetos maiores? Quais as implicações negativas vc vê no padrão? Eu gostei um bocado de um paper que vc citou sobre repositories, mas eles tem a maior cara de DAO, ou talvez eu não tenha entendido corretamente.
Sobre o controle de transações, não dava para construir numa camada acima do dominio já que isso é mais tranqueira do que algo relacionado diretamente ao dominio?
Mas existem transações que fazem parte do modelo, como em uma venda, você tem que garantir que todos os objetos podem ser vendidos antes de fechar uma venda e depois que fechar você não pode mais vender eles pra outra pessoa.
