Desculpe, não entendi sua dúvida.
Você disse :
… e depois disse:
Você já não tinha criado suas classes (de maneira mais organizada possível)? O que é maneira organizada? Porque criar DTOs (é uma aplicação distribuída usando EJB 2.x)?
hehehe d"e uma procurada no f[orum por VOs, DTO, etc. te dará uma luz…
[quote=java_coffe] Nâo estou utilizando DTO …So quiz dizer que eu ja modelei meu diagrama de classe agora quero criar a persistencia da minha aplicação .
Quero saber como eu modelo da melhor forma a parte de persistencia da minha aplicação !? Eu crio as classes de acordo com as tabelas do banco :?: :?:
[/quote]
Mas pq fazer isso se vc já criou suas classes de negócio? É elas que você tem que utilizar, e não réplicas do seu banco de dados.
Quando vc realizar alguma consulta no banco, retorne seus objetos de negócio.
Bom, no seu caso, seria algo do tipo.
Se você utilizar DAO (a classe abaixo é o básico do básico):
classe ProdutoDao{
private produto;
public Produto obtemProdutoMaisVendido(){
Connection conn ...
String SQL = "select * from ..."
for(...){
produto = new Produto(rs.getLong("id"), rs.getString("nome") ... ) ;
}
return produto;
}
}Vc não precisa ter um DAO para cada Tabela, mas preferencialmente para cada Entidade “forte” de seu negócio.
Pode tbm tentar o uso de DAOs Genéricos (dê uma busca rapida neste forum sobre isso).
Mas sinceramente, não reinvente a roda, use um framework[2].
Depende da aplicação e cada caso é um caso.
Se sua entidade de negócio precisar de algo na camada de persistência, vc pode colocar como atributo de sua entidade um repositorio de dados e delegar consultas a este repositório de dentro de sua entidade (só não deve, ou melhor, geralmente não se recomenda, acessar diretamente a API de persitência (JDBC, JPA, ou qualquer coisa do gênero) de dentro de uma entidade).
Seu repositório de dados pode ser a interface de um DAO especialista daquele domínio ou uma classe especialista que contenha um DAO genérico como atributo.
OBS: Se bem que isso não é regra… um repositório de dados pode ser qualquer coisa que armazene dados, desde que seus métodos sejam voltados ao negócio, e não para infra de acesso a dados. Dado a isso dizemos também que um repositório faz parte do negócio e não da persistência.
Amém.
[quote=Lezinho]Bom, no seu caso, seria algo do tipo.
Se você utilizar DAO (a classe abaixo é o básico do básico):
classe ProdutoDao{
private produto;
public Produto obtemProdutoMaisVendido(){
Connection conn ...
String SQL = "select * from ..."
for(...){
produto = new Produto(rs.getLong("id"), rs.getString("nome") ... ) ;
}
return produto;
}
}Vc não precisa ter um DAO para cada Tabela, mas preferencialmente para cada Entidade “forte” de seu negócio.
Pode tbm tentar o uso de DAOs Genéricos (dê uma busca rapida neste forum sobre isso).
Mas sinceramente, não reinvente a roda, use um framework[2].[/quote]
Parece um Repository.
Fabio… leia os posts que se seguiram …
Lezinho, fazendo um gancho nesse assunto, como exatamente uma aplicação é distribuida ?
Entendo que os DTO’s são para a comunicação entre as camadas físicas da aplicação (e não lógicas) portanro o DTO trafegaria entre servidores no caso. Mas você consegue me exemplificar isso ?
Desculpa se a pergunta for muito simples, mas realmente queria visualizar um exemplo de “aplicação distribuida” onde precise trafegar um VO/DTO ou o que seja…
O EJB pode oferecer interfaces remotas para qualquer aplicativo local Java que vc desejar.
Um exemplo do seu uso é na concetração de lógicas de negócio em processos remotos e compartilhar tais processos em aplicativos ou front-ends diferentes (como com os webservices, que tbm são modelos distribuídos de programação). Não estou afirmando que esse modelo de programação seja bom ou ruim, Fowler por exemplo faz sérias objeções quanto a isso (ou pelo menos de como isso era implementado em Java nas suas versões anteriores).
Uma outra usabilidade é rodar os processos em clusters, ou em núcleos diferentes de CPUs.
Bom, se você utilizar o modelo J2EE de desenvolvimento distribuído (Session e EntityBeans) sem utilizar padrões como SessionFaçade ou TO (DTO), você terá sérios probelmas de performance.
Na antiga especificação EJB 2.x, um EntityBean possui interface remota para todos seus métodos gets e sets. Imagine que para cada utilização de simples objeto.getNome(), ou usuario.setSenha(‘xxx’), sejam realizadas chamadas remotas, isso é um absurdo. Para isso se criavam objetos fakes (os DTOs) não distribuíveis (não EJBs) e serializáveis, com vários atributos de um ou vários EntityBeans. Estes objetos deveriam ser manipulados por um client local da forma que se queira e enviados uma única vez para um objeto distribuído (quase sempre um EJB SessionFaçade). Então remotamente, este objeto era desmembrado (padrão Assembler) em verdadeiros objetos de domínio EntityBean, que então são manipulados na persistência.
Hoje em dia, não existe mais por que fazer isso. Os EntityBeans se transformaram em Entities JPA, locais e serializáveis. Ele mesmo navega entre as camadas locais e remotas.
Como você vê, utilizar DTOs sem que esteja em uma aplicação distribuída e com a antiga especificação, não faz sentido.
Legal Lezinho, sua resposta clareou algumas coisas.
Duas dúvidas
-
Nunca implementei um webservices sem ser Rest. Por Rest um servidor fazia uma solicitação em forma de URL que seria interpretada por outro servidor, que responderia um xml. No primeiro servidor então faria um parse (seja com XStream, jDom, ou o que seja) para criar um objeto. Ou seja, não precisei trafegar o objeto fisicamente. Via webservices comum seria muito diferente justificando o uso do DTO ?
-
Nos clusters que ja disponibilizei as aplicações que trabalhei, nunca fiz transferencia de objetos “conscientemente”, ou seja, se existe alguma comunicacao trafegando objetos isso fica a cargo do servidor de aplicação. O DTO nesse caso seria usado pelo servidor de aplicação ?
Entendo que como WebService “comum”, você esteja se referindo a utilização de SOAP e end-points ao estilo JAX-RPC (não que isso seja de fato o “comum”, mas talvez um formato bastante difundido … é isso mesmo?). De qualquer maneira, creio que sua pergunta é: utilizar ou não DTOs em WebService… a resposta é “não”.
Não faz sentido, uma vez que o WebService expõem end-points de serviço e não métodos de acessibilidade a atributos de objetos de domínio (você não tem métodos getters e setters expostos em um webService ). Um Webservice pode ser comparado a um Session Bean (obviamente muito mais heterogêneo), e não a um Entity Bean.
Lembre-se que os DTOs são meios de economizar chamadas remotas a antigos EntityBeans e não a Sessions, para estes ultimos usamos Session Façade.
Quando você passa um objeto como parâmetro em uma chamada de um webservice (o que normalmente se atribui o nome de “tipos complexos”), tal objeto pode ser um POJO qualquer, inclusive uma entidade JPA com métodos de negócio.
Em um parque de clusters, você tem várias JVMs… espalhadas entre as máquinas, ok? Quando você trabalha com objetos distribuídos, como EJBs, a única referência que você tem são as interfaces, você não sabe em qual máquina pode estar a implementação.
Por tanto, você pode ter seu framework web trabalhando em uma máquina, e o EJB estar em outra. O responsável por realizar o algoritmo para replicação dos estados no parque, gerenciar o contexto JNDI, a atualização, o escalonamento e outras atividades de infraestrutura é o APPServer com seu conteiner EJb. Se a sua aplicação utiliza EntityBean 2.x e seu ambiente é conforme eu descrevi, quem deve criar DTOs para evitar possíveis chamadas remotas desnecessárias é o desenvolvedor… o conteiner EJB faz o papel dele apenas distribuindo e gerenciando os objetos.
Se você não utiliza EJB, mas sua aplicação esta em cluster, então não existe este problema. As chamadas vão ser sempre locais. Quando sua aplicação muda de host, leva consigo todas as suas classes e objetos, portanto ao reivindicar um objeto, este estara na própria JVM do objeto solicitante, logo não a necessidade de criar objetos para trafegar em camadas físicas já que estão na mesma.
Gente eu modelei meu diagrama de classe onde as classes estao todas modeladas de uma forma mais organizada possivél !!!
Agora to querendo criar a parte de persistência do banco sendo que nao vo utilizar o hibernate . No caso eu tenho que criar as minhas classes de acordo com modelo relacional do banco de dados(VO,DTO) esse tipo de coisa !?
É dessa forma ou tem uma forma diferente de fazer isso !?
Agradeço a quem ajudar .
Nâo estou utilizando DTO …So quiz dizer que eu ja modelei meu diagrama de classe agora quero criar a persistencia da minha aplicação .
Quero saber como eu modelo da melhor forma a parte de persistencia da minha aplicação !? Eu crio as classes de acordo com as tabelas do banco :?: :?:
Vc diz isso quando eu criar os DAO !?
Nele eu realizado toda a parte de persistencia !? Sendo que o retorno eu mando para as minhas classes de negocios !?
Valeu . No caso a classe que possuir a funcionalidade eu crio um DAO para ela !?
Exemplo.: Na classe Gerente eu tenho uma operação chamada cadastro funcionario . No caso essa operação eu coloco dentro de um DAO ao ives da propria classe Gente !?
Muito Obrigado pela Ajuda …Você ajudo muito a sanar um pouco das minhas duvida !!!
Deus abençoe carinha !!!