Como separar as camadas

Programação Arquitetura
#1

Gostaria de saber como separar as camadas…

Tenho a entidade que é o Empregado, e esse empregado tem o EmpregadoManager, que grava o mesmo no banco.

Agora as regras de negócio eu teria que criar o EmpregadoRN certo?

Como ficaria essa classe? Ela somente alteraria dados do objeto que passei como parametro? E caso necessite verificar as disciplinas que este empregado tera de lecionar este ano eu teria de criar uma classe EmpregadoFacade, para buscar as metrias e gravar na tebela de EmpregadosMaterias?

#2

[quote=joshh]Gostaria de saber como separar as camadas…

Tenho a entidade que é o Empregado, e esse empregado tem o EmpregadoManager, que grava o mesmo no banco.

Agora as regras de negócio eu teria que criar o EmpregadoRN certo?

Como ficaria essa classe? Ela somente alteraria dados do objeto que passei como parametro? E caso necessite verificar as disciplinas que este empregado tera de lecionar este ano eu teria de criar uma classe EmpregadoFacade, para buscar as metrias e gravar na tebela de EmpregadosMaterias?[/quote]

Por que nao manter suas regras nas proprias classes de dominio? afinal é assim que a OO diz. sobre persistencia, seria tambem igualmente possivel e limpo manter nas classes de dominio, mas uma solucao via repository ou dao´s, ou ainda injecao via AOP nas classes dominio, sao boas ideias.
No que se baseou para nomear a classe de persistencia como ‘EmpregadoManager’? OBS: seguir uma linguagem comum e padronizada facilita a comunicacao do seu time, e.g. padrao de nomenclatura adotado por padroes de projeto consolidados.

#3

Peguei o projeto andando, e foi assim que denomiram as classe… Estou tentando arrumar as coisas.

Como esta hoje é o seguinte:

Package Model:

@Entity
@Table(name="EMPRESAS")
@NamedQueries({
	@NamedQuery(name="empresa.max",query="SELECT MAX(e.id) FROM Empresa e")
	})
	
public class Empresa implements Serializable , IAuditoria {
	private static final long serialVersionUID = 1L;

	@Id
	private Long id;

    @ManyToOne
	@JoinColumn(name="CIDADE", referencedColumnName = "ID")
	private Cidade cidade;
}[/code]

Package Service eu tenhos Managers. Seria o DAO no caso, Não?
[code]@Bean(name = "empresaManager")
@Transactional
public class EmpresaManagerImpl extends ManagerImpl<Empresa, Long> implements EmpresaManager {
	
	@ConstructorArgs(@Property(bean = "sessionFactory"))
	public EmpresaManagerImpl(SessionFactory sessionFactory){
		super(sessionFactory);
	}
	
	@SuppressWarnings("unchecked")
	@Override
	public List<Empresa> consultaPorCnpj(String cnpj) {
		Criteria crit = getSession().createCriteria(Empresa.class);
		
		Criterion cnpjMasc = Restrictions.eq("cnpj",cnpj);
        Criterion cnpjSemMasc = Restrictions.eq("cnpj",cnpj.replace("/", "").replace("-", "").replace(".", ""));
        LogicalExpression orExp = Restrictions.or(cnpjMasc,cnpjSemMasc);
        crit.add(orExp);		
		
		return crit.list();
	}	

	public void gravar(Empresa empresa) {		
		if (empresa.getId() == 0) {		//modo insercao
			//seta novo id  
			empresa.setId(getSelectMax("empresa.max"));
			
			getSession().persist(empresa);
		} else { 	//modo atualizacao
			getSession().update(empresa);
		}
	}

A minha duvida toda surgiu pois tenho as Regras de Negócio no Facade…

#4

Para lógica que se refira a uma entidade de negócio apenas ou a ela e entidades dependentes, podes usar o bom senso de manter tal lógica na entidade, mas para aquelas mais elaboradas que envolvam mais entidades, acessos a banco e etc, pode concentrar em services. Se a forma como você está usando Facade for esta, ok, mas você também tem controllers ou por acaso está misturando o que é tratamento de requisições com facades? Se sim à ultima pergunta, tente isolar o que é negocio em services, do que é controle em controllers.

#5

Veja se estou certo:

EmpregadoFacade.java

[code]@Bean(name = “empregadoFacade”)
public class EmpregadoFacadeImpl implements EmpregadoFacade {

private EmpregadoRN empregadoRN;
    private EmpregadoObjetosRN empregadoObjetosRN;
	
public void atualizarObjetos(Empregado empregado) {
                empregadoVO = new EmpregadoVO;
                .
                .
                empregadoObjetosRN.atualizar(empregadoVO);
        
}

[/code]

EmpregadoObjetosRN.java

@Bean(name = "empregadoObjetosRN")
@Transactional
public class EmpregadoObjetosRNImpl implements EmpregadoObjetosRN {
	private EmpregadoManager empregadoManager;
	private EmpregadoObjetosManager empregadoObjetosManager;
		
	public void atualizar(empregadoVO) {
                 empregadoManager.getById(empregadoVO);
                 
                 //Atualiza e grava no banco
		
	}

Esta correto? Controller chama o facade atraves do ManagedBean ao clicar em um botão na tela… Facade Chamas as Regras de Negócio e a regra de negócio busca no banco e apos grava. Caso fosse um cadastro básico sem Regra de Negócio eu não teria o Facade e o RN e utilizaria o Manager direto para gravar. Estou no caminho certo?

#6

Não vi sentido em segmentar as lógicas de negócio nas camadas de entidade + RN + facade. Não te parece suficiente encaixar todas as regras de negocio possiveis nas suas entidades, e aquelas que nao couberem entram numa camada secundaria de negocio, que no caso é um service ou um facade?
Em resumo: no seu exemplo nao parece necessario haver tanto seus RN quanto seus facades

#7

Haviam me falado para que no model
Classes @Entity somente deveria ficar os dados referentes a tabela do banco de dados. O manager somente quando necessario realizar consultas com base de dados ou gravar. E as regras de negócio no Facade. Caso eu precisasse por exemplo pegar dados de uma tabela, analisar e com o resultado gravar determinado item em outra. Continua muito confuso para mim.

#8

[quote=joshh]Haviam me falado para que no model
Classes @Entity somente deveria ficar os dados referentes a tabela do banco de dados. O manager somente quando necessario realizar consultas com base de dados ou gravar. E as regras de negócio no Facade. Caso eu precisasse por exemplo pegar dados de uma tabela, analisar e com o resultado gravar determinado item em outra. Continua muito confuso para mim.[/quote]

Desse modo vc estaria programando estruturado.
Pra que ter objetos burros que só carregam dados e não sabem nem o que fazer com eles?
Mantenho minhas lógicas na própria entidade, agora quando uma regra trabalha com mais de uma entidade, separo em um Service.

#9

Algumas regras fazem sentido adicionar a entidade, porém quando eu necessitar realizar uma mais complexa por exemplo:

Ao Gravar um tela(entidade x) devo atualizar várias tabelas filhas e adicionar novos registros. Após adicionado esses registros, devo obter todos as todas as entidades y que estão vinculadas entidade x. Após obter estes registros devo atualizar uma outra série de tabelas referentes a tabela Y e seus filhos. A dúvida vem a ser, devo implementar todas essas chamadas na Implentação do Facade ou devo criar uma classe de regras de negócios para cada entidade, para percorrer a determinada lista e então gerar os registros necessários?

#10