Entidades inteligentes X entidades anemicas

Boa tarde pessoal, estou procurando respostas até hoje não encontradas, seguinte, hoje em dia se fala muito sobre entidades inteligentes, não anemicas(javaBeans), então gostaria da opinião de vocês, quando eu implemento toda a lógica de negocio referente a minha entidade, nela mesma, a necessidade de um contrololador, mas não o Facade e sim uma camada de negocio mesmo?

resumindo, como ficaria um modelo correto, usando entidades inteligentes? até hoje nunca consegui concretizar isso!

A camada “Service” fica muito mais fina, mas ela ainda é necessária, segue alguns links que me passaram quando tive uma dúvida assim:

http://www.arquiteturajava.com.br/livro/cuidado-com-o-modelo-anemico.pdf

vlw vou dar uma lida sim, aguardo mais opiniões

http://fragmental.com.br/wiki/index.php/Evitando_VOs_e_BOs.html

[quote=RafaelCassau]Boa tarde pessoal, estou procurando respostas até hoje não encontradas, seguinte, hoje em dia se fala muito sobre entidades inteligentes, não anemicas(javaBeans), então gostaria da opinião de vocês, quando eu implemento toda a lógica de negocio referente a minha entidade, nela mesma, a necessidade de um contrololador, mas não o Facade e sim uma camada de negocio mesmo?

resumindo, como ficaria um modelo correto, usando entidades inteligentes? até hoje nunca consegui concretizar isso![/quote]

É preciso tomar cuidado com o termo “entidades inteligentes” para não desrespeitar as responsabilidades dessas entidades. Se ela está conhecendo muitos detalhes de outras entidades, recebendo listas enormes de parametros (mais que um), indo buscar coisas externas e assim por diante, é sinal de que ela está “inteligente” demais.

Uma entidade deve agir sobre os seu próprios atributos e nada que vá alem disso.

digaoneves , eu tenho o livro de arquitetura, e já li ele 2 vezes, realmente é muito bom, creio que não me expressei bem, toda essa parte teórica eu já tenho uma certa compreensão, o que eu quero saber, por exemplo e como eu persistiria minha entidade, como eu chamaria meu DAO por exemplo, pois até hoje faço isso através de um BO, se for usar entidades inteligentes a chamada do save ficaria onde, na minha própria entidade ou em uma BO?

Ataxexe , gostei muito do link, comprei recentemente o Core J2ee Patterns também, estou ancioso para le-lo porem ainda não chegou, porem a minha duvida ainda persiste, da mesma forma como escrevi acima, mas agradeço a ajuda.

YvGa, eu me atento bastante sobre baixo acoplamento e alta coesão, justamente por isso fiz a pergunta, preciso descrobrir realmente qual é o limite de certa inteligencia na minha entidade.

[quote=RafelCassau]digaoneves , eu tenho o livro de arquitetura, e já li ele 2 vezes, realmente é muito bom, creio que não me expressei bem, toda essa parte teórica eu já tenho uma certa compreensão, o que eu quero saber, por exemplo e como eu persistiria minha entidade, como eu chamaria meu DAO por exemplo, pois até hoje faço isso através de um BO, se for usar entidades inteligentes a chamada do save ficaria onde, na minha própria entidade ou em uma BO?

Ataxexe , gostei muito do link, comprei recentemente o Core J2ee Patterns também, estou ancioso para le-lo porem ainda não chegou, porem a minha duvida ainda persiste, da mesma forma como escrevi acima, mas agradeço a ajuda.

YvGa, eu me atento bastante sobre baixo acoplamento e alta coesão, justamente por isso fiz a pergunta, preciso descrobrir realmente qual é o limite de certa inteligencia na minha entidade.[/quote]

Minha opinião: Este tipo de assunto foi muito discutido (não sei porque parou) quando se falava em DDD, portanto procure sobre DDD para obter mais informações; conclusões e soluções não posso garantir que você irá encontrar rsrsrsr.

Estas dúvidas aparecem muito por causa disto:

  1. Construção do sistema orientado para o modelo de dados.
  2. Negligencia ao aplicar a análise orientada a objetos e principalmente a programação orientada a objetos.
  3. Influencia da estrutura da dados legada no sistema.
  4. Dificuldade em abstrair aspectos relacionados a infraestrutura, processo, serviço, modelo e etc…
  5. Não utilização de bancos de dados orientados a objetos.
  6. Mesmo utilizando banco de dados orientados a objetos ainda é necessário decidir o save fica no entidade ou no seu BO; isto pode levar a pensar se a sua aplicação realmente tenha que se preocupar com estas questões, talvez não tenha.

flws

[quote=fantomas]conclusões e soluções não posso garantir que você irá encontrar rsrsrsr.

flws[/quote]

Toda religião é baseada na fé, OO não é diferente.

Tem esse “meta-post” com uma coleção de links sobre o assunto:

http://www.guj.com.br/java/23944-entao-voce-gostaria-de-discutir-oop

Várias tópicos do guj onde esse tipo de coisa foi discutido.
Vale a pena dar uma olhada.

E afinal de contas, a chamada do save ficaria onde, na própria entidade rica ou no BO?

:wink:

[quote=RafaelCassau]digaoneves , eu tenho o livro de arquitetura, e já li ele 2 vezes, realmente é muito bom, creio que não me expressei bem, toda essa parte teórica eu já tenho uma certa compreensão, o que eu quero saber, por exemplo e como eu persistiria minha entidade, como eu chamaria meu DAO por exemplo, pois até hoje faço isso através de um BO, se for usar entidades inteligentes a chamada do save ficaria onde, na minha própria entidade ou em uma BO?

Ataxexe , gostei muito do link, comprei recentemente o Core J2ee Patterns também, estou ancioso para le-lo porem ainda não chegou, porem a minha duvida ainda persiste, da mesma forma como escrevi acima, mas agradeço a ajuda.

YvGa, eu me atento bastante sobre baixo acoplamento e alta coesão, justamente por isso fiz a pergunta, preciso descrobrir realmente qual é o limite de certa inteligencia na minha entidade.[/quote]

[quote=novata]E afinal de contas, a chamada do save ficaria onde, na própria entidade rica ou no BO?

:wink:

[quote=RafaelCassau]digaoneves , eu tenho o livro de arquitetura, e já li ele 2 vezes, realmente é muito bom, creio que não me expressei bem, toda essa parte teórica eu já tenho uma certa compreensão, o que eu quero saber, por exemplo e como eu persistiria minha entidade, como eu chamaria meu DAO por exemplo, pois até hoje faço isso através de um BO, se for usar entidades inteligentes a chamada do save ficaria onde, na minha própria entidade ou em uma BO?

Ataxexe , gostei muito do link, comprei recentemente o Core J2ee Patterns também, estou ancioso para le-lo porem ainda não chegou, porem a minha duvida ainda persiste, da mesma forma como escrevi acima, mas agradeço a ajuda.

YvGa, eu me atento bastante sobre baixo acoplamento e alta coesão, justamente por isso fiz a pergunta, preciso descrobrir realmente qual é o limite de certa inteligencia na minha entidade.[/quote][/quote]

procuro anciosamente por essa resposta, até por isso comprei o livro “Padrões de Arquitetura de Aplicações Corporativas” de Matin Fowler, que diz respeito sobre MVC, arquitetura distribuida, Value Object ou Data Trasnfer Object, assim que possuir uma resposta eu posto aqui.

Esse assunto de entidades inteligentes também me deixou muito intrigado.

Recentemente estive pensando no assunto e até cheguei a criar entidades com lógicas de persistência.

@Entity
public class Cliente {

	//atributos...

	public void salvar(EntityManager em) {
		//grava ou atualiza a si mesmo
	}

	public void remover(EntityManager em) {
		//remove a si mesmo da base
	}

	public List<Cliente> listarPorID(EntityManager em, int ID) {
		//busca clientes por ID
	}

	public List<Cliente> listarPorNome(EntityManager em, String nome) {
		//busca clientes por nome
	}

	public List<Cliente> listarPorPedido(EntityManager em, Pedido pedido) {
		//busca clientes por pedido
	}

}

Logo percebi que não fazia sentido (ou posso estar enganado) um cliente gravar a si mesmo no banco de dados ou ainda realizar consultas que retornem outros clientes.

Por esse motivo, acho que faz muito mais sentido apenas chamar o método merge() ou remove() do EntityManager para ações simples de inserção ou remoção de entidades da base de dados na própria ação de um botão, como por exemplo:

@ManagedBean
public class ClienteMB {

	//atributos...
        Cliente c;
	EntityManager em;

	public void salvar(ActionEvent e) {
		//grava ou atualiza um cliente
                em.merge(c);
	}

	public void remover(ActionEvent e) {
		//remove um cliente
                em.remove(c);
	}

}

Ou ainda criar uma classe especifica para cuidar de consultas ou de lógicas mais complexas de inserção ou remoção de entidades:

public class ClienteDAO {

	//atributos...

	EntityManager em;

	public void salvar(ActionEvent e) {
		//grava ou atualiza um cliente com logica complexa
	}

	public void remover(ActionEvent e) {
		//remove um cliente da base com logica complexa
	}

	public List<Cliente> listarPorID(ActionEvent e, Cliente c) {
		//busca clientes por ID
	}

	public List<Cliente> listarPorNome(ActionEvent e, Cliente c) {
		//busca clientes por nome
	}

	public List<Cliente> listarPorPedido(ActionEvent e, Pedido pedido) {
		//busca clientes por pedido
	}

}

Por isso acho que os métodos de entidade devem refletir o que aquela entidade faz, e somente isso.

Na minha opinião, não faz sentido um cliente gravar ou remover a si próprio ou a outros clientes da base, por isso, faria muito mais sentido que essas funções fossem executada por uma outra classe responsável unicamente por gerenciar a interação da entidade com o banco de dados.

Essa foi a impressão que tive observando essas situações.

Vamos ver o que o pessoal mais experiente tem a dizer sobre o assunto.

Obrigado e até mais pessoal.

Fazer a entidade se persistir é o que Martin Fowler chamou de Active Record, no livro já mencionado neste tópico.

Sobre colocar lógica de negócio nas entidades… Ainda tem gente que não faz isso? Sério? :roll:

[quote=tnaires]Fazer a entidade se persistir é o que Martin Fowler chamou de Active Record, no livro já mencionado neste tópico.

Sobre colocar lógica de negócio nas entidades… Ainda tem gente que não faz isso? Sério? :roll: [/quote]

Sobre o Active Record, em linguagens estaticas eu nao gosto muito deles, acabam poluindo demais o código e dando mais responsabilidade a classe do que ela deveria ter. Em linguagens dinamicas ele fica quase transparente, fica bem melhor.

Eu continuo usando os bons e velhos daos para salvar/consultar entidades.

Sobre colocar regra de negocio em entidades: é impressionante o numero de gente que ainda não faz isso.

[quote=tnaires]Fazer a entidade se persistir é o que Martin Fowler chamou de Active Record, no livro já mencionado neste tópico.

Sobre colocar lógica de negócio nas entidades… Ainda tem gente que não faz isso? Sério? :roll: [/quote]

Você não faz idéia do quanto :smiley:

Não existe o termo “Entidades inteligentes”…na verdade, nos chamamos isso de “DOMAIN MODEL” q é o uso correto do OOP.
Procure material sobre isso…
Vai alguns

  • Pojo em Ação
  • Padrões de Arquitetura de Aplicações Corporativas
  • Domain Drive Design
    Tudo esta escrito ai…
    Depois de tudo assimilado…bem vindo ao mundo OOP.
    Bons estudos…