Respeitosamente, discordo quando você diz que o actionListener é uma simples mensagem. O actionListener acopla a View a quem quer que exponha a operação. Se eu renomear o método no MB vou ter que renomear na View, então há acoplamento direto entre os dois… Não faz sentido a View enviar uma mensagem diretamente para o Model, certo?
Eu entendo isso como uma operação da View, pois é papel do Controller receber eventos da View e traduzi-los para operações sobre o Model.
Certo, acopla sim, da mesma forma que se você chamar um método de uma classe dentro de outra.
Imediatamente você acoplou as duas classes através de um contrato comum (Método), é dessa forma que os objetos trocam mensagens, via chamada de métodos.
Lógicamente se você altera o contrato você quebra a conexão.
Isso não quer dizer que ambas as classes fazem o mesmo papel!
Se você considerar seu Botão um UIComponent claramente seu ManagedBean será outra classe, ambas estão trocando mensagens entre sí, concorda ?
Pedro, é questão de ponto de vista, eu acho. Na minha opinião, um único Controller para um sistema inteiro, é muito estranho… Mais estranho ainda quando encontro um MB com um método toggleSubmitButton()… Para mim, se torna claro que há mistura de responsabilidades…
Se for um FrontController não se torna estranho
Pode perceber que todas a informações de fluxo da apresentação você declara de forma implicita ou via faces-config.
Outro ponto, no MB você trabalha com FacesEvent disparado pelo seu UIComponent(ActionListener) mas não existe retorno é uma comunicação unilateral entre a VIEW e o MODEL. Conforme ilustrado na figura:
ao meu ver, o que você descreve é um Presentation Model (criado por Fowler) e não o Model de MVC.[/quote]
Velho não estou.
Não confunda controle da aplicação com controle de fluxo entre MODEL e VIEW!
Também não ache que a VIEW não pode requisitar o MODEL diretamente.
Olha eu montei aquele modelo baseado no que eu entendi do DDD(Domain Driven Design).
Então, vamos por partes:
Sim, eu chamo de Integração porque minha aplicação poderia ter diversos tipos de persistencia (Banco de Dados OO, Relacional, Arquivo).
Seria uma camada de serviços da Aplicação, onde teria interfaces que externalizam serviços complexos da aplicação.
Serviços que poderiam lidar com várias entidades do negócio ao mesmo tempo.
link: http://martinfowler.com/eaaCatalog/serviceLayer.html
Fica em ambas. Eu tento dividir por tipo de comportamento.
O que seria seu BO? Talves eu entenda de forma diferente.
Acho que se encaixaria melhor nessa camada sim. Apesar que eu não levei esse padrão com consideração naquele modelo.
Então nesse modelo que eu tentei propor, a grande maioria das regras e comportamentos do negócio deveriam estar na camada de Domínio (Entidades, Value Objects, Entidades Agregadas).
Desculpa a demora para responder, estive meio sem tempo esses dias.
Pois é, no DDD uma entidade é um objeto do modelo do domínio(Negócio) com identidade e comportamentos bem definidos. Não confunda com “entity bean” do J2EE(JPA).
No caso um método “gerarCartão” eu colocaria na própria entidade Cartão e dependendo do modelo os métodos de CRUD também.
A verdade é que há várias formas de fazer.
Um ponto chave que eu gosto de lembrar é que você deveria tentar separar a lógica principal do negócio em uma única camada. (Nesse caso a Domain).
A camada de apllication deve se manter bem fina e delegar responsabilidade a camada de domain.
Outro ponto: Se você alterar um componente do sistema em uma camada em quantas outras você deve mexer? Se a resposta for todas…então existe algo errado no seu modelo. (O ideal seria 1).
Erick, você está misturando patterns de origens diferentes: Business Object é descrito em J2EE Core Patterns e Entidade é descrito em Domain Driven Design.
Os dois tem objetivos similares: a criação de objetos de domínio inteligentes que encapsulem lógica e dados.
Entidade vai mais além e define que Entidades são apenas os conceitos que possuem uma identificação transcendente aos dados encapsulados, ou seja, o objeto mantém a mesma identidade independente de qualquer mudança interna de estado.
O Prisioneiro 999 continua sendo o mesmo Prisioneiro, mesmo que seja transferido de Prisão, sua pena seja reduzida em 50%, seu verdadeiro nome seja descoberto ou sua lista de crimes seja apagada. Não importa, ele ainda é o mesmo Prisioneiro.
Um Business Object é somente um objeto de domínio que encapsula lógica e dados. Eu vejo como um primeiro passo na direção de um projeto com domínio mais rico. DDD pode ser encarado como uma linguagem de padrão que define tipos especializados de BOs (Factories, Repositories, VOs, Entities, etc.).
[quote=erickfm8]Intendi, só mais uma pergunta, eu posso ter o metodos de crud na minha entidade? eu fica errado, temque ter uma classe para separa ,
Temque ter uma classe a parte neh?[/quote]
Na verdade os métodos CRUD estariam declarados por uma interface Repository. (conforme modelo na figura).
Você pode implementar Repository dentro da Entidade. Ou em um DAO separado. Entendeu?
Já vi muitas discussões a esse respeito e na verdade não cheguei a uma conclusão. No livro do Eric Evans nos exemplos, ele faz a agregação do Repository na própria entidade.
