Caros amigos,
Hoje me surgiu uma duvida, no padrão DAO, na classe que implementa esse padrão eu posso ter alguma regra ? por exemplo, na minha classe eu tenho o metodo incluirPedido(Pedido pedido). Quero que antes de incluir este pedido verifique se ele existe, se existir eu quero que atualize ou retorne um erro. Esse tipo de regra pode estar contida ai ?
[quote=icefox]Caros amigos,
Hoje me surgiu uma duvida, no padrão DAO, na classe que implementa esse padrão eu posso ter alguma regra ? por exemplo, na minha classe eu tenho o metodo incluirPedido(Pedido pedido). Quero que antes de incluir este pedido verifique se ele existe, se existir eu quero que atualize ou retorne um erro. Esse tipo de regra pode estar contida ai ? [/quote]
Não. As regras, ou ficam uma camada acima (em uma arquitetura mais procedural, chamariamos de camada de negocio, onde teria os BusinessObjects), ou no próprio POJO (verificar wikipédia).
Você tem que entender, que o DAO é pattern enquanto fazer apenas uma coisa: acesso a dados. Ele é burro, só manda, recebe e lista dados. Mais nada, sem regras de negocios lá.
Ok? 
DAO’s nao possuem regra de negócio nem envolvem objetos de domínio.
Listar todos os registros de uma tabela que possuem data de nascimento maior que D não é uma regra de negócio?
Listar todos os registros de uma tabela que possuem data de nascimento maior que D não é uma regra de negócio?[/quote]
Bom,
pelo menos eu, neste caso deixo essa regra da data de nascimento no DAO mesmo. Pois, ela estará na query que vai pro banco e
a única coisa que eu vou fazer é ler o rs e retornar uma lista populada. E daria um nome pro método de getPeopleByBirthDate(Date).
Regras de negócio que envolvam seleção de dados acho que vale a pena estar no banco, até para a aplicação estar mais performática,
não faz sentido trazer um milhão de usuários para depois no java separar 10 que nasceram naquela data…
O DAO me parece que deveria ter regras de como consultar os dados.
Regras de como trabalhar com os dados ou o que fazer com ele deveria estar numa camada acima.
Listar todos os registros de uma tabela que possuem data de nascimento maior que D não é uma regra de negócio?[/quote]
Bom,
pelo menos eu, neste caso deixo essa regra da data de nascimento no DAO mesmo. Pois, ela estará na query que vai pro banco e
a única coisa que eu vou fazer é ler o rs e retornar uma lista populada. E daria um nome pro método de getPeopleByBirthDate(Date).
[/quote]
Ou será Repository?
Não. Mas anexar um cupom de desconto, para as pessoas com mais de 20 anos, ao enviar um email de feliz aniversário para os seus clientes é uma regra de negócio.
Por mais óbvio que pareça a definição, a seguir, ainda é válido citá-la:
Recuperar os registros de uma tabela filtrando por uma campo que representa a pela data de nascimento é igual em qualquer sistema.
Enviar um cupom de desconto, junto a carta de feliz aniversário; só acontece na empresa XPTO. Na XYZ, são dois cupons.
[quote=icefox]Caros amigos,
Hoje me surgiu uma duvida, no padrão DAO, na classe que implementa esse padrão eu posso ter alguma regra ? por exemplo, na minha classe eu tenho o metodo incluirPedido(Pedido pedido). Quero que antes de incluir este pedido verifique se ele existe, se existir eu quero que atualize ou retorne um erro. Esse tipo de regra pode estar contida ai ? [/quote]
Pode porque é uma regra de persistencia. Vc está verificando se o objecto já existe e está decidindo entre um insert e um update. Isso é normal.
Para aumentar a performance normalmente é bom manter registro do estado do objeto para não ter que fazer o select e decidir mais facilmente (por exemplo, colocar uma coluna numerica sequencial. Se o objeto tem esse campo preenchida é porque já foi gravo antes e portanto faz-se update. Caso contrário insert.
O Repository é a classe de domínio que expõe o DAO, para as outras classes de domínio.
Mais explicações sobre o assunto em uma discussão sobre DAOs e classes de negócio, que aconteceu aqui no GUJ.
Recomendo, principalmente o resumo, com diagrama de classes, do Philip Calçado sobre onde entra o Repository. E o resumo de uma linha, feito pelo saoj e corrigido pelo Philip Calçado, sobre como ficam as classes em um projeto usando o padrão Repository.