fiz uma implementação aqui, gostaria da opiniao de voces …
public interface ActiveRecord {
public void salvar();
public void carregar();
public void alterar();
public void excluir();
}
[code]public abstract class AbstractActiveRecord implements ActiveRecord {
public void alterar() {
Repositorio.alterar(this);
}
public void carregar() {
Repositorio.carregar(this);
}
public void excluir() {
Repositorio.excluir(this);
}
public void salvar() {
Repositorio.salvar(this);
}
}[/code]
[code]public abstract class Repositorio {
public static void carregar(ActiveRecord registro) {
DAOFactory.getDAO(registro).carregar();
}
//…
}[/code]
[code]public abstract class DAOFactory {
public static GenericoDAO getDAO(ActiveRecord registro) {
if(registro.getClass().getName().equals("estrutura.BeanTemplate"))
return new BeanDAO(registro);
return null;
}
}[/code]
[code]public class BeanDAO extends GenericoDAO {
public BeanDAO(ActiveRecord registro) {
super();
this.registro = registro;
}
@Override
public ActiveRecord carregar() {
//BeanTemplate bean = new BeanTemplate();
//bean.setId(3);
//bean.setNome("Leandro");
((BeanTemplate) this.registro).setId(1);
((BeanTemplate) this.registro).setNome("Rafael");
return null;
}
}[/code]
bem simplorio mesmo …
e nao estou botando muita fe
tsc tsc tsc …
o que eu acho que ficou estranho é que a minha DAO nao retorna nada, diferente das minhas DAOs tradicionais que retornavam um objeto.
enfim, to meio perdido … conto com a colaboração de voces …
Eu gosto de java, adoro na verdade, mas fazer um monte de classe e dezenas e dezenas de linha só pra persistir um objeto, é abusar da nossa boa vontade.
programo em java ha um mes, estou aprendendo, venho aqui no forum pra pedir opinioes que possam me ajudar.
caso nao tenha alguma opiniao ou sugestao que possa ajudar a mim ou quem acompanha o topico NAO POSTE.
essa implementação eu recolhi pela internet, agora nao me recordo o site, aparentemente alguem aqui do proprio forum foi quem fez, caso alguem tenha alguma coisa a mais a acrescentar, fique a vontade
ao senhor Luiz Aguiar agradeço por sua fantastica contribuição
Calma amigo, não fique bravinho não, não falei específico de vc ou do seu código não, falei de maneira genérica sobre as mais comuns implementacões de persistencia que fazemos em Java, geralmente várias classes, dezenas de linhas, foi isso que eu quiz dizer.
Tente ler com mais atencão tá… e não precisa se exaltar com os companheiros do forum, aqui todos de uma forma ou outra tentamos ajudar
Gosto muito desse assunto, é um dos meus prediletos.
É um assunto muito polêmico e geralmente sai alguma discussão mais acalorada.
Eu acho que o grande lance do desenvolvedor Java é a arquitetura e a estruturação das suas aplicações.
E acredito que é o grande diferencial e pelo que vejo é a parte mais carente do mercado Java.
É relativamente simples aprender uma nova tecnologia Java, um framework, etc, mas estruturar uma aplicação é difícil.
Uma frase (mais ou menos assim) muito legal eu li do livro “Aplicando UML e padrões”
[quote=pcalcado]Use transações declarativas e pare de se preocupar com isso
Mas geralmente vai de cada necessidade. Leia o livro do Fowler onde existe uma discussão interessante a respeito.[/quote]
Ja dei uma boa lida nesse livro! Porém num me lembro dele ter falado explicidamente em transações declarativas, falou? Onde?? !!!Tenho que ler dinovo e melhor!!!
Aproveitando o assunto, quem tiver um “tempinho” (eu tive!), pode dar uma lida no que rolou nessa thread do forum do spring “DAO Reference Inside an Entity Domain Object”… É o tipo de discussao que nao se chega a uma conclusao definitiva, mas faz vc ver um monte de ideias e problemas que talvez vc nunca tivesse pensado antes.
Não, não, ele fala de AR x Mappers, o sentido deve ter ficado estranho na minha frase :S
De qualquer modo, persistência e objetos sempre é algo complicado. Apesar de saber que em muitos lugares isso é difícil (inclusive meus atuais projetos) o uso de um framework ORm decente (i.e. Hibernate) é quase obrigatório.
Não dá pra pensar em fazer JDBC em 2007, exceto para relatórios, OLAP e cenários bem adversos.
Basicamente, ao utilizar DAOs dentro de objetos você quebra Camadas, já que a Camada de Negócios passa a ter ciência sobre a implementação de paersistência. Se você usar a abstração de Repositories pode aliviar bastante isso e chegar a um Domain Model sem interferência direta da infra-estrutura, especialmente utilizando DIP (Mundo Java #17).
A partir do momento em que você abstrai o DAO, chega um ponto interessante. Se você parte do princípio que o domain model deve mapear o mundo que está sendo ‘digitalizado’, acrescentar métodos como save() pode facilmente quebrar sua abstyração. O orgasmo do DDD é quando se msotra um diagrama de classes ao cliente e ele entende 100%, dando inclusive bons palpites. Se existem termos e conceitos técnicos como persistir e recuperar objetos este entendimento fica comprometido.
Na minha experiencia, projetos pequenos (webapps especialmente) se beneficiam muito de ARs mas para coisas mais complexas realmente um Mapper se faz necessário. Se você trabalha direto com JDBC esqueça AR, ou você acaba criando um framework apra lidar com ORM ou simplesmente não funciona, AR é uma opção para quem tem uma ferramenta ORM disponível.
