Arquitetura de Sistema (Desktop)

O que vcs acham dessa arquitetura pessoal???
criticas?
sugstões?

Obrigado!

Por que a necessidade de Cliente, ClienteEntity, ClienteManager ? É tudo a mesma coisa …

O que seria AppFacade ? Não entendi …

Quanto as perguntas …
Gosto de pensar em um esquema de repository.
Você pode injetar o dao sem problema.

Obrigado nbluis ;;;

Cliente seria o meu VO, onde teria get e set…

ClienteEntity criarei para metodos auxiliares de cliente, como por exemplo: no meu cliente tenho um getDataCadastro() que me retorna um date, já no meu clienteEntity terei getDataCadastroAux() que me retornara uma String com a data formatada, somente exemplo.

Meu ClienteManager, é onde terei minas regras de negocio…

Quanto ao AppFacade é uma interface que conterá contratos entre Controle e Modelo e AppFacadeImpl implementará esta interface…

entendeu???

Obrigado…

p.s. Pode me falar mais sobre este esquema de repository???

Bom…
Quanto ao seu Cliente e ClienteEntity, acho que seria perfeitamente possível ser o mesmo objeto independente de qualquer coisa.
Utilize métodos transient para fazer seus “métodos auxiliares”.

Acho que seria legal você dar uma olhada também em DDD(Domain Driven Design), e buscar do fundo do baú o artigo do Shoes sobre Fantoches quanto ao seu ClienteManager.(OBS: é apenas uma observação, não é uma regra)

Qual o papel de seu AppFacade?

Aqui no GUJ tem bastante material sobre o assunto.
Uma busca rápida.

http://www.guj.com.br/posts/list/60/26218.java
http://www.guj.com.br/posts/list/74015.java

Vou dar um exemplo de como utilizarei o AppFacade:

Interface AppFacade

public interface AppFacade {

	public UsuarioVO recuperaUsuarioPorLogin(String login);
}

AppFacadeImpl

public class AppFacadeImpl implements AppFacade {
	public UsuarioVO recuperaUsuarioPorLogin(String login) {
		UsuarioDAO dao = (UsuarioDAO) getDAO(UsuarioDAO.class);
		return dao.recuperaUsuario(login);
	}
}

FIcou claro?

Quando ao Cliente e ClienteEntity, pode ser no mesmo objeto mesmo, mas separei para melhor entendimento…

Seu AppFacade tem um conceito parecido com o de repository.

O problema é.
AppFacade vai ser um Megazord de buscas de todas as entidades do sistema?

Enquanto isso, em uma abordagem talvez mais “saudável” você poderia ter algo como.

public class UsuarioRepository {
  public Usuario recuperaUsuarioPorLogin(String login) {
    //faz a brincadeira de consulta aqui e retorna o usuario
  }
}

Entende ??

E é claro, um repository para cada entidade do seu sistema que necessitar recuperar registros de algum repositorio.

Esse repositório por sua vez pode trabalhar com o dao.

Lembre-se dos Fantoches

Não li ainda os topicos q vc me passou… mas pelo q estou entendendo, minas regras de negocio ficariam neste repositorio…???

Quanto ao Facade so o utilizarei quando eu precisar que o controle converse com o modelo ou seja… se por exemplo, quero executar recuperaUsuarioPorLogin(), e para isto não preciso entrar na camada de controle… eu posso fazer isto no meu manager… e o meu Facade pode tb conversar diretamente com meu Dao… como no exemplo…

Entendeu?

diegonunes.sistema:

Não li ainda os topicos q vc me passou… mas pelo q estou entendendo, minas regras de negocio ficariam neste repositorio…???

Existem alguns problemas nessa abordagem.
Primeiro, morre o encapsulamento e o reuso de código. Pois voce vai estar implementando as mesmas regras no seu “manager”, no “facade” e ainda onde mais quiser.

Outro problema é expor e sobrecarregar entidades em seu comportamento.
Lembre-se antes de tudo sobre abordagem OO.
Seus objetos devem ter características e comportamento. Porém com coesão.

Jogar métodos auxiliares em classes globais, é assinar um sistema anti-oo trabalhando proceduralmente.

Veja os links acima, que vai entender do que falo.

Regras de Négocio…
tipo para mim cadastrar um cliente, preciso verificar x do mesmo…
é uma regra…

vou dar uma olha no links e volto a postar…

Muito Obrigado!!!