[quote=$ERVER]Oi drsmachado, que bom vc por aqui, admiro muito o seu conhecimento.
Então active record, se não me falha a memória, é fazer a persistência no próprio objeto?[/quote]
Exato.
Partindo do pressuposto que cada objeto deve conter sua própria lógica, ele também pode ser responsável por sua persistência.
De qualquer forma, o padrão DAO (que inclui os DAOs e DTOs) é um padrão acomodado, mesmo usando frameorks ORM as pessoas abusam deste modelo, o que acaba sendo uma redundância (afinal, estamos abstraindo uma abstração).
E, quanto ao meu conhecimento, eu sou apenas mais um. Tuas respostas aqui estão me deixando bem animado, achei bacana.
Por favor, esqueça a palavra POJO. Pense na classe e suas responsabilidades - pois é disso que trata o MVC, divisão de responsabilidades.
No MODEL - sua classe - temos os atributos e os métodos que fazem operações sobre eles. representando assim um objeto do mundo real. Uma pessoa não tem somente o atributo nome, mas também fala, anda, paga contas, etc … Então esses métodos precisam estar na classe.[/quote]
O POJO é um elemento arraigado na mente de muitos desenvolvedores java que vieram da programação estruturada e/ou que são mais antigos. Aí eles ensinam seus alunos a usarem e isso fica arraigado nos mais novos.
Quando eu aprendi MVC, o que foi passado é o mesmo que o rlanhellas está discursando. Mas pouco a pouco você consegue ver que cada camada pode conter mais de um tipo de classe e que cada classe terá suas responsabilidades bem divididas. Aí você percebe que MVC trata de camadas e responsabilidades e não apenas de Model View Control.
Isso é uma prática que divide opiniões, também.
Em minha opinião, fazer isso deixa a classe com mais de uma responsabilidade - o que não se pode fazer na OO. Mas há quem defenda AR, e respeito muito quem o faça, é apenas minha opinião.
então drsmachado, como falei acima, na minha opinião não é algo legal pra se fazer, e pode dar problemas depois - digo isso porque já fiz e tive dores de cabeça.
Quanto aos DAOs e DTOs, ficam estranhos também, concordo contigo.
E ainda é humilde, tem todo o meu respeito!
Talvez eu esteja confundindo algumas coisas aqui, conto com a sua ajuda na correção se eu falar alguma bobeira, tudo bem?
[quote]O POJO é um elemento arraigado na mente de muitos desenvolvedores java que vieram da programação estruturada e/ou que são mais antigos. Aí eles ensinam seus alunos a usarem e isso fica arraigado nos mais novos.
Quando eu aprendi MVC, o que foi passado é o mesmo que o rlanhellas está discursando. Mas pouco a pouco você consegue ver que cada camada pode conter mais de um tipo de classe e que cada classe terá suas responsabilidades bem divididas. Aí você percebe que MVC trata de camadas e responsabilidades e não apenas de Model View Control.[/quote]
Perfeito! Comigo aconteceu exatamente o mesmo. Tanto que ainda hoje, depois de 3 anos ainda surge alguma dúvida quanto a MVC, ai recorro ao fórum tmb. Mas o que o drsmachado disse, concordo em 100%!
Verdade drsmachado, o conceito de POJO é tão forte que fica difícil de aprender outro tão facilmente e esquecer que no Java Bean podemos fazer um CRUD também, não só Getters e Setters.
A questão que mais me incomoda é definir o que há de fato na camada MODEL do MVC, pois V são os formulários (GUI), C são os Controllers e M são os models.
Se estivermos falando de ACTIVE RECORDS então na Camada MODEL podemos considerar apenas os Java Beans com CRUDS, certo ?
Correto. Porém, deixe de usar um pouco a palavra “camada” e substitua por “responsabilidade”, metanlize isso, pois MVC é divisão de responsabilidades, e não de camadas - as camadas são divididas apenas pra organização.
[quote=rlanhellas]Verdade drsmachado, o conceito de POJO é tão forte que fica difícil de aprender outro tão facilmente e esquecer que no Java Bean podemos fazer um CRUD também, não só Getters e Setters.
A questão que mais me incomoda é definir o que há de fato na camada MODEL do MVC, pois V são os formulários (GUI), C são os Controllers e M são os models.
Se estivermos falando de ACTIVE RECORDS então na Camada MODEL podemos considerar apenas os Java Beans com CRUDS, certo ?[/quote]
Uma primeira ação para se livrar disso é tentar enxergar o MVC apenas como sigla e não como base da idéia. Você pode ter 4, 5, 6, 10 camadas em uma aplicação com MVC, cada qual contendo classes com responsabilidades bem definidas.
Outro ponto é questionar a necessidade de cada um dos gets ou sets dos pojos. Num POJO tudo possui getter e setter, mesmo sendo desnecessário. Se é desnecessário, não precisa colocar, não acha?
Tem outra questão em utilizar o Active Record, como o Hibernate trata isso ?
Pelo que trabalho até hoje (com POJOS e DAOS) os CRUD’s feitos pelo Hibernate são sempre feitos em classes diferentes dos POJOS.
Isso não quer dizer que deva estar num package chamado “br.com.suaempresa.model”. Então, não se trata de camadas, e sim de responsabilidades.
Consegui explicar melhor ou tem algo que ficou estranho ainda?
O que pode estar lhe confundindo são os requisitos funcionais - uma determinada condição pra aplicação continuar sua execução normal. MVC não trata disso - isso é tratado com Orientação a Aspectos, outra técnica de programação que usa reflexão computacional, e tem seu uso muito controverso na comunidade também.
Ficou claro sim, a responsabilidade da lógica de negócio deve estar toda no próprio objeto.
PORÉM, TODAVIA, ENTRETANTO, isso não iria deixar o mesmo sobrecarregado ? Uma SUPERCLASSE de 5mil linhas ? Pois além de ter os seus getters e setters ainda terá: CRUD, sessões hibernate, injeção de dependência e outros recursos necessários.
É por isso que sou contra o CRUD no objeto, e qualquer responsabilidade atribuída a classe que não seja relacionada ao domínio.
Cada um dos recursos que você citou, não são nativos do Java - apesar da maioria ter suas especificações para guiar o desenvolvimento de ferramentas que as façam - portanto, se precisa delas, recorra as essas ferramentas.
Resumindo: por MODEL entenda que são suas classes - as quais tem apenas seus atributos e métodos com as operações que elas realizam.
Desculpe mas a definição de POJO não é simplesmente de um objeto anêmico com getters e setters…
Embora POJO na minha opnião, não seja nada mais que um objeto Java comum (diferente de um EJB que implementa determinadas interfaces), nada impede dele ter lógicas de negócio e não ser um objeto anêmico.
Minha ideia é o seguinte, para minha aplicação MVC:
1 - br.com.meuprojeto.bean (Todos os POJOS ficam aqui)
2 - br.com.meuprojeto.dao (Todos os DAOS ficam aqui)
3 - br.com.meuprojeto.bo (Todos os Business Object ficam aqui e se comunicam com o DAO, como se fosse um Repository)
4 - br.com.meuprojeto.bd (Business Delegate - é o Controller)
5 - br.com.meuprojeto.gui (Frames da aplicação)