Duvidas desenvolvimento JSF + Hibernate

Front-end
#1

Olá pessoal, estou iniciando no mundo java, seguindo um livro de java para web. Cheguei ao passo final onde todas as classes abaixo já foram criadas, mas fiquei com dúvidas em relação a separação MVC delas.


@Entity
public class Usuario implements Serializable {

    @Id
    @GeneratedValue
    private Integer codigo;
    private String nome;
    private String email;

Até aqui legal, parte do model usuário.

public interface UsuarioDAO {

    public void salvar(Usuario usuario);
    public void atualizar(Usuario usuario);
    public void excluir(Usuario usuario);
    public Usuario carregar(Integer codigo);
    public Usuario buscaPorLogin(String login);
    public List<Usuario> lista();
}

A interface DAO do usuário.

public class UsuarioDAOHibernate implements UsuarioDAO {

    private Session session;

    public void setSession(Session session) {
        this.session = session;
    }

    public void salvar(Usuario usuario) {
        this.session.save(usuario);
    }

Implementação da interface, setando a sessão do hibernate.

public class UsuarioRN {

    private UsuarioDAO usuarioDAO;

    public UsuarioRN() {
        this.usuarioDAO = DAOFactory.criarUsuarioDAO();
    }

Aqui começa minhas dúvidas, essa RN(regras de negocio) seria o controller?
Porque é declarado a interface usuarioDAO e não a implementação UsuarioDAOHibernate?

public class DAOFactory {

    
    public static UsuarioDAO criarUsuarioDAO() {
        UsuarioDAOHibernate usuarioDao = new UsuarioDAOHibernate();
        usuarioDao.setSession(HibernateUtil.getSessionFactory().getCurrentSession());
        return usuarioDao;
    }

Porque dessa classe DAOFactory? Se a sessão do hibernate já foi declarada na classe UsuarioDAOHibernate?

Fiquei muito confuso com tantas classes tratando o mesmo “assunto”.

#2

Evite utilizar DAO quando utiliza hibernate. Hibernate já faz o que o DAO se propõe/deveria fazer.
Se for utilizar, faça-o com DAO genérico, em uma abstract class. Fica mais fácil de gerenciar e menos poluído.
Outro ponto, você deve sempre utilizar a interface, pois isso garante o encapsulamento e a aplicação correta da OO.
Particularmente, eu criaria uma super interface (BaseDAO<E, ID extends Serializable>) e criaria uma Usuario que estendesse da super interface.
Então, criaria a AbstractDAO<E, ID extends Serializable> que seria a superclasse da classe UsuarioDAOImpl que implementa a UsuarioDAO.

public interface BaseDAO<E, ID extends Serializable>{
    public void gravar(E e) throws Exception;
    //demais métodos genéricos
}

public interface UsuarioDAO extends BaseDAO<Usuario, Long>{
    //métodos específicos de usuário
}

public abstract class AbstractDAO<E, ID extends Serializable>{
    private Session session;
    private Transaction tx;
    protected void init(){
        session = HibernateUtil.getSession();
        tx = session.beginTransaction();
    }

    protected void end(){
        session.close();
    }

    protected void commit(){
        tx.commit();
    }

    protected void rollback(){
        tx.rollback();
    }

    public void gravar(E e) throws Exception{
        try{
            init();
            session.save(e);
            commit();
        }catch(Exception ex){
            rollback();
            throw ex;
        }finally{
            end();
        }
    }

    //demais métodos a serem implementados
}

public class UsuarioDAOImpl extends AbstractDAO<Usuario, Long> implements UsuarioDAO{
    public void gravar(Usuario e) throws exception{
        super.gravar(e);
    }
    //demais métodos
}
#3

Essa classe seria o Controller,só está muito mal nomeado,n tem nada a ver ser nomeado como Regras de Negócio.

#4

[quote=raf4ever][quote]
public class UsuarioRN {

    private UsuarioDAO usuarioDAO;  
  
    public UsuarioRN() {  
        this.usuarioDAO = DAOFactory.criarUsuarioDAO();  
    }

Aqui começa minhas dúvidas, essa RN(regras de negocio) seria o controller?
[/quote]

Essa classe seria o Controller,só está muito mal nomeado,n tem nada a ver ser nomeado como Regras de Negócio.[/quote]

Pois é, também achei um tanto estranho esse nome, mas pelo menos agora sei que é um Controller.

#5

[quote=drsmachado]Evite utilizar DAO quando utiliza hibernate. Hibernate já faz o que o DAO se propõe/deveria fazer.
Se for utilizar, faça-o com DAO genérico, em uma abstract class. Fica mais fácil de gerenciar e menos poluído.
Outro ponto, você deve sempre utilizar a interface, pois isso garante o encapsulamento e a aplicação correta da OO.
Particularmente, eu criaria uma super interface (BaseDAO<E, ID extends Serializable>) e criaria uma Usuario que estendesse da super interface.
Então, criaria a AbstractDAO<E, ID extends Serializable> que seria a superclasse da classe UsuarioDAOImpl que implementa a UsuarioDAO.

[code]
public interface BaseDAO<E, ID extends Serializable>{
public void gravar(E e) throws Exception;
//demais métodos genéricos
}

public interface UsuarioDAO extends BaseDAO<Usuario, Long>{
//métodos específicos de usuário
}

public abstract class AbstractDAO<E, ID extends Serializable>{
private Session session;
private Transaction tx;
protected void init(){
session = HibernateUtil.getSession();
tx = session.beginTransaction();
}

protected void end(){
    session.close();
}

protected void commit(){
    tx.commit();
}

protected void rollback(){
    tx.rollback();
}

public void gravar(E e) throws Exception{
    try{
        init();
        session.save(e);
        commit();
    }catch(Exception ex){
        rollback();
        throw ex;
    }finally{
        end();
    }
}

//demais métodos a serem implementados

}

public class UsuarioDAOImpl extends AbstractDAO<Usuario, Long> implements UsuarioDAO{
public void gravar(Usuario e) throws exception{
super.gravar(e);
}
//demais métodos
}

[/code][/quote]

drsmachado interessante essa implementação…mas como seria o funcionamento sem o DAO? em que classe eu trataria a persistencia?

#6