Eu to acompanhando o tópico pra ver as sugestões, esses daos genéricos tbm não me agradam na totalidade, simplemente pq tenho q cirar uma classe pra cada dao, emsmo sem ter nenhum método específico.
Usar composição seria interessante, o Vraptor teria algum jeito de fazer algo do tipo:
public class ClienteController{
ClienteController(Dao<Cliente> daoCliente){
...
}
...
}
se alguém tiver um exemplo…
[quote=mario.fts]Eu to acompanhando o tópico pra ver as sugestões, esses daos genéricos tbm não me agradam na totalidade, simplemente pq tenho q cirar uma classe pra cada dao, emsmo sem ter nenhum método específico.
Usar composição seria interessante, o Vraptor teria algum jeito de fazer algo do tipo:
public class ClienteController{
ClienteController(Dao<Cliente> daoCliente){
...
}
...
}
se alguém tiver um exemplo…
[/quote]
É exatamente nisto que estou pensando, em usar composição, e tambem estou usando o vRaptor.
Estive lendo o exemplo de composição do Effective Java, Josh Bloch, e estava pensando em adapta-lo para Daos,
ficaria ± assim:
public class BaseDao<T> implements Dao<T>
//este BaseDao faria as operações basicas de CRUD aplicavel a todas as entities
a partir dai usar composição para daos espeficicos, não saquei muito bem a necessidade do “ForwardingDao” que teria que criar seguindo o exemplo do livro, ainda estou vendo
E ainda teria que como ficaria a DI do vRaptor, como vc citou.
não li o tópico todo, mas deixa eu alfinetar:
eu não gosto de DAO caso esteja utilizando algum framework de persistência. Para CRUD uso logo os métodos Session.xxx() ou entityManager.xxx(). Vc pode encapsular eles em uma classe sua como PersistenceManager, por exemplo. Já as Queries, vc pode colocar em objetos próprios. Por exemplo:
Usuario u = PersistenceMng.queryFirst(new ObterUsuarioPorLoginESenha("thiago", "1234");
List<Prova> provas = PersistenceManager.queryAll(new ObterProvasPorAlunoEAno(u, 2010));É um exemplo básico - mas a partir daí é só explorar a idéia e melhorá-la.
To com preguiça de dar quote… :lol:
Thiago Senna:
Eu tbm gosto dessa idéia , mas apenas para sistemas muito simples. Eu tive uma situação onde um processo em específico precisava ser feito em jdbc direto, por conta da performance, e tive q reescrever um monte de classes por não ter a persistencia encapsulada dentro de um Dao. A idéia do dao genérico deveria ser essa mesma, funcionar como um entitymanager.
[EDIT] se bem que vendo sua implementação, ela seria mais um dao genérico que usar o entitymanager direto to certo? [/EDIT]
fredferrao:
Sim, é nisso mesmo q eu tava pensando. no caso, o exemplo foi infeliz, o certo seria injetar o dao genérico no dao específico, caso fossem necessárias operações específicas. caso não tivesse essa necessidade, poderia injetar o dao normal mesmo.
veja se a idéia é muito maluca:
public interface Dao<T>...
//define as operações comuns
public class BaseDao<T> implements Dao<T>
//implementa as operações comunscaso não tivessem operações especiais, faria assim:
public class CargoController{
CargoController(Dao<Cargo> cargoDao, ...){
...Caso precisasse de alguma operações especial, ai implementaria em uma classe separada
public interface ClienteDao extends Dao<Clietne>...
//define as operações específicas
List<Cliente> listaPorTipo(Tipo tipo);
public class ClienteDaoImpl implements ClienteDao{
public ClienteDaoImp(Dao<Cliente> dao){...}
//implementa as operações específicas e delega para o basedao as operações básicase poderia injetar no controller
public class ClienteController {
ClienteController(ClienteDao clienteDao, ...){
...o ideal é que desse pra fazer dessa maneira tbm, para os casos onde estas operações não fossem necessárias:
public class ClienteController {
ClienteController(Dao<Cliente> clienteDao, ...){
...Mas ai acho que já estariamos esbarrando em limitações do java mesmo
To viajando muito? 
[quote=mario.fts]To com preguiça de dar quote… :lol:
Thiago Senna:
Eu tbm gosto dessa idéia , mas apenas para sistemas muito simples. Eu tive uma situação onde um processo em específico precisava ser feito em jdbc direto, por conta da performance, e tive q reescrever um monte de classes por não ter a persistencia encapsulada dentro de um Dao. A idéia do dao genérico deveria ser essa mesma, funcionar como um entitymanager.
[EDIT] se bem que vendo sua implementação, ela seria mais um dao genérico que usar o entitymanager direto to certo? [/EDIT]
[/quote]
Bom, nao se trata de um DAO. O PersistenceManager é uma classe que encapsulou o Session do hibernate, por exemplo, mas nada impediria de vc utilizar direto o hibernate. Seria algo mais parecido com o padrão UnitOfWork mesmo. As classes Queries são POJO`s simples. Nada demais.
Se for realmente rolar JDBC ai a idéia que sugeri não é um bom negócio. Daí a estratégia de DAO é a ideal mesmo. Mas se tiver certeza q começa com Hibernate e nunca vai mudar para JDBC, ai a opinião que sugeri pode ser legal, IMHO.
[quote=Thiago Senna][quote=mario.fts]To com preguiça de dar quote… :lol:
Thiago Senna:
Eu tbm gosto dessa idéia , mas apenas para sistemas muito simples. Eu tive uma situação onde um processo em específico precisava ser feito em jdbc direto, por conta da performance, e tive q reescrever um monte de classes por não ter a persistencia encapsulada dentro de um Dao. A idéia do dao genérico deveria ser essa mesma, funcionar como um entitymanager.
[EDIT] se bem que vendo sua implementação, ela seria mais um dao genérico que usar o entitymanager direto to certo? [/EDIT]
[/quote]
Bom, nao se trata de um DAO. O PersistenceManager é uma classe que encapsulou o Session do hibernate, por exemplo, mas nada impediria de vc utilizar direto o hibernate. Seria algo mais parecido com o padrão UnitOfWork mesmo. As classes Queries são POJO`s simples. Nada demais.
Se for realmente rolar JDBC ai a idéia que sugeri não é um bom negócio. Daí a estratégia de DAO é a ideal mesmo. Mas se tiver certeza q começa com Hibernate e nunca vai mudar para JDBC, ai a opinião que sugeri pode ser legal, IMHO.[/quote]
Sim, exatamenteo o que eu pensei (no segundo momento). Na primeira leitura achei que vc tava falando de usar o Entitymanager diretamente nas classes, no lugar onde vc usaria o dao. Foi esse o erro que eu cometi. Mas desse jeito que vc propos até daria pra usar jdbc, bastaria apenas que seu PersistenceMng fosse uma interface, e no caso de necessiada vc muda a implementação usada conforme sua necessiadade.
estou obtendo:
java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
quando tento executar um DAO similar ao seu.
this.oClass = (Class<ENTITY>) ( (ParameterizedType) getClass().getGenericSuperclass()).
getActualTypeArguments()[0];