Camada Model

Programação Arquitetura
#1

Bom dia.

Ontem estava conversando com um amigo sobre o padrão MVC e surgiu uma dúvida sobre a camada de Model. No model colocamos as regras de negócios e ae surge a dúvida.
Por exemplo eu tenho um JavaBean chamado Produtos, dentro dele eu tenho os atributos e métodos get/set além de um construtor Default. Esse Bean é exatamente igual a minha tabela no banco de dados (ela não possui nenhum relacionamento).
Para trabalhar com as operações do banco de dados, como insert, delete, update, select e etc, eu implemento elas dentro do meu Bean, por exemplo, crio um método chamado salvarDados dentro do Bean? ou isso é responsabilidade de outra classe (lembrando que não estou usando Hibernate e nenhuma camada de persistência, irei fazer usando JDBC puro mesmo).

Obrigado

#2

Crie uma classe específica para isso. Um padrão bastante usado é o DAO.

Se, por exemplo, seu bean se chama pessoa:

class Pessoa()

String getNome();
void setNome( String nome );

Sua classe DAO teria métodos mais ou menos assim:

class PessoaDAO()
void save( Pessoa p );
void update( Pessoa p );
void delete( Pessoa p );

Sacou?

#3

legal LIPE
mas a responsabilidade do DAO não é de fazer a conexão com o banco de dados, armazenar um objeto Connection (geralmente usando singleton) e outras classes usarem esse objeto?

Não ficaria mais lógico usar o DAO para inciar uma conexão com o banco de dados, abrir um objeto Connection e nos Bean fazer os métodos de insert, delete… (ficando mais fácil até mesmo para a modelagem do sistema) ??? (a conversa com meu amigo também chegou nesse ponto, e ae que surgiu a dúvida).

#4

Olá

Cuidado com singletons que na maioria das vezes não são necessários e as vezes não são tão singletons como a gente pensa. Explico com mais detalhes em: http://www.guj.com.br/forum/viewtopic.php?t=14615

[]s
Luca

#5

Pelo que ja li e entendo, é interessante usar as classes DAO da forma
que o LIPE falou.

Um motivo : Se vc colocar os metodos de persistencia no seu bean, e sua aplicacao precisar funcionar em mais de um BD ( ex: Em determinadas situacoes Oracle, outras MySql, … ), os seus beans ficarao bastante complexos ( devido ao tratamento dos diversos BDS ). Vc colocando os metodos de persistencia na DAO, vc mantem a simplicidade de seus beans e todo tratamento relacionado a persistencia de dados fica na DAO, ou seja, nao mistura Modelo com persistencia. :wink:

#6

Alex, você pode criar uma classe específica para fornecer uma conexão à classe DAO.

#7

A idéia por traz do DAO é retirar toda a lógica de persistencia e comunicação com o BD das classes de negócios.
O problema do DAO estático ( onde cada entidade de dados tem uma classe DAO relativa ) é que vc na maioria das vezes repete muito código.
Gosto de implementar DAOs usando reflection ou um XML de configuração das entidades que o DAO vai lidar, dessa forma vc tem uma única classe de DAO para todas as suas entidades e pode gerar todo o SQL das entidades em algum método de warm-up.
Se vc está em um ambiente web ( AppServers ) vc deve obter suas conexões de um pool de conexões, esse é um recurso básico em qualquer AppServer. Se vc está em um ambiente client/server é interessante que vc tenha uma classe que gerencie este pool de conexões e que será responsável por fornecer conexões para cada Thread em execução.
Se vc está usando EJBs como facades então vc já tem uma ambiente transacional, mas se está em desktop vc deve se preoculpar também com as transações.
Acho que vale a pena considerar o uso de algum mecanismo de persistencia, como Hibernate ou Entity Beans, pois existem questões como caching que são complexas de se implementar.

#8

Êpa, o conceitômetro acusa problemas :splat:

Não é porque você não usa um componente de persistência [Hibernate, JDO, etc.] que você não tem uma camada de persistência.

Você pode muito bem implementar sua camada de persistência com JDBC, arquivos properties, arquivos csv, arquivos txt, XML, SGBD hierárquicos/OO/rede… qualquer coisa que dure um reboot :wink:

[]s

#9

Obrigado pelas resposta pessoal.
Não vou implementar nada assim, foi só uma conversa com meu amigo caso fosse implementar algo usando JDBC puro.
Perguntei se deve colocar métodos nos modelos, pois quando se lê coisa sobre modelagem, geralmente vemos métodos “inserir, remover” dentro dos próprios modelos, então fiquei nessa dúvida.

Agora sobre camada de persistência. Lendo o tutorial de hibernate aqui do GUJ, temos uma classe chamada UsuarioDAO, pelo que eu vi, ele é responsável apenas pelo modelo Usuario. Em um projeto real, o certo seria então criar apenas UMA classe DAO genérica, onde carregamos todas os modelos no SessionFactory e depois passamos os Objects como parametros para os métodos? ou é aconselhável criar um DAO para cada modelo? (UsuariosDAO, ClientesDAO,ProdutosDAO?) ou ainda assim criarmos 1 classe pai, e outras classes filhas utilizando Herança?

Quantas dúvidas :roll: :roll: :roll:

#10

Claro que há métodos comuns a todas as classes DAO, mas nem todos né? Pelo menos nos projetos desenvolvidos sempre há um monte de métodos diferentes para cada modelo.

Ao invés de ficar me coçando e gastando um monte de recursos pra implementar algo do tipo:

public class GenericDAO
{
    public void insert( Object o )
    {
        // bastante código pra descobrir qual classe o objeto é
        db.insert( model );
    }
}

Prefiro repetir 2-3 métodos nas classes.

Mas isso é muito peculiar. Se você acha que seu projeto vai ganhar bastante implementando algo assim, vá em frente.

#11

Olhe aqui:
http://www.guj.com.br/forum/viewtopic.php?t=6734
:wink:

Generalizar ou não depende do escopo q vc quer da aplicação(e o tamanho do Projeto…)

#12