[quote=emerleite]Já discuti isso (e muito) com o Gustavo pessoalmente nesta semana, então não vou me repetir textualmente.
O ponto que eu acho que a maioria defende é o fato de não fazer BDUF e a filosofia de YAGNI. Não faz muito sentido fazer implementações na base da suposição, como por exemplo: Vou interfaciar usando DTOs, pois estou prevendo acesso remoto.
[/quote]
Mas sempre concordamos, o simples é melhor.
[quote=Gustavo Serafim][quote=sergiotaborda]
Por outro lado, o desenho do exemplo de funcionário não contém métodos que alteram o estado do sistema, logo, não ha nenhum perigo em invocar esses métodos de qualquer outra camada. [/quote]
Alterar um atributo de instância de um objeto de negócio não é alterar o estado do sistema? Se você esta falando de base, esses objetos podem ser gerenciados por um mapeamento objeto relacional como, por exemplo, o Hibernate.
[/quote]
É discutível.
1)Gostando ou não de getters and setters, eles mantém o encapsulamento na camada de domínio. Você não mudou o estado em outra camada, você sugeriu para o setter(que esta no domínio) assim o fazer … Dependendo da implementação deste útlimo, ele altera o estado do objeto (de forma persistível ou não).
2)Mesmo se assim não fosse (suponhamos que o atributo fosse público), o objeto de negócio poderia ter seu estado de forma transitória, já que a classificação de alterado poderia ser somente quando este atinge o status de ‘pronto’, através de alguma implementação de sustentação deste estado (persistindo ou serializando por exemplo). Nestes casos, alterar um atributo pode não significar mudar seu estado, já q ele não esta ‘pronto’ (se alguém solicitar pelo seu identificador, atraves de um repositório este mesmo objeto, ele estaria com outro estado, diferente que o seu).
O ponto 2 que coloquei é verdade dependendo de implementacoes de cache e proxies utilizadas no sistema.
[quote=Gustavo Serafim][quote=sergiotaborda]
Por outro lado, o desenho do exemplo de funcionário não contém métodos que alteram o estado do sistema, logo, não ha nenhum perigo em invocar esses métodos de qualquer outra camada. [/quote]
Alterar um atributo de instância de um objeto de negócio não é alterar o estado do sistema?
[/quote]
Não. É apenas alterar o estado do objeto.
O estado do sistema é o conjunto de todos os objetos consistentes e válidos. Mesmo que invocar o set não dê erro, ainda têm que ser tomadas outras providencias para que esse objeto passe a integrar o estado do sistema. Normalmente alterações de estado do sistema são feitas dentro de transações. Invocar set() não tem que ser feito numa transação.
[quote=Lezinho][quote=Gustavo Serafim][quote=sergiotaborda]
Por outro lado, o desenho do exemplo de funcionário não contém métodos que alteram o estado do sistema, logo, não ha nenhum perigo em invocar esses métodos de qualquer outra camada. [/quote]
Alterar um atributo de instância de um objeto de negócio não é alterar o estado do sistema? Se você esta falando de base, esses objetos podem ser gerenciados por um mapeamento objeto relacional como, por exemplo, o Hibernate.
[/quote]
É discutível.
1)Gostando ou não de getters and setters, eles mantém o encapsulamento na camada de domínio. Você não mudou o estado em outra camada, você sugeriu para o setter(que esta no domínio) assim o fazer … Dependendo da implementação deste útlimo, ele altera o estado do objeto (de forma persistível ou não).
2)Mesmo se assim não fosse (suponhamos que o atributo fosse público), o objeto de negócio poderia ter seu estado de forma transitória, já que a classificação de alterado poderia ser somente quando este atinge o status de ‘pronto’, através de alguma implementação de sustentação deste estado (persistindo ou serializando por exemplo). Nestes casos, alterar um atributo pode não significar mudar seu estado, já q ele não esta ‘pronto’ (se alguém solicitar pelo seu identificador, atraves de um repositório este mesmo objeto, ele estaria com outro estado, diferente que o seu).
O ponto 2 que coloquei é verdade dependendo de implementacoes de cache e proxies utilizadas no sistema.[/quote]
Acredito que pode ser discutível, depende da abstração.
No caso usei um prefixo set…, mas estou representando um método de negócio.
Então melhor ainda. Quem tem o método de negócio, como você mesmo descreveu, é o método “set” é ele que pode (mas não necessariamente faz) a alteração de estado. O execute do Command é um delegador para o domínio (entre outras atividades), mas não tem regra quanto a ele.
Então melhor ainda. Quem tem o método de negócio, como você mesmo descreveu, é o método “set” é ele que pode (mas não necessariamente faz) a alteração de estado. O execute do Command é um delegador para o domínio (entre outras atividades), mas não tem regra quanto a ele.[/quote]
Não vejo problema nessa abordagem, mas não tive ainda oportunidade de trabalhar em um sistema tão simples, que não justifica um “Service Layer”
Então, neste caso, fica estranho um método transacional de negócio sendo executado fora da API da aplicação.
Não chamaria o método setSalario na apresentação.
Por isso eu comentei:
Phillip, qual parte? “Proteger a implementação” ajuda diminuir o acoplamento. “Manter objetos sempre em estado consistente” ajuda muito quando temos muitas regras complexas. Quando temos muitas trocas de mensagens para cumprir uma regra complexa, podemos inserir erros de lógica de negocio mais facilmente quando os objetos ficam inconsistentes em algum momento.
[/quote]
Eu perguntei o que se ganha com objetos burros comparados à simplesmente ter interfaces.
São úteis e possuem aplicação, mas interfaces não vão representar uma hierarquia paralela nem requerer código de mapeamento. Se você for pagar o preço de ter que mudar UsuarioDTO e CoisaQueTransformaUsuarioEmUsuarioDTO toda vez que Usuario mudar é bom ter uma razão para isso ou é simplesmente desperdício.
[quote=Lezinho]Invocação não significa implementação do domínio… o código continuara na camada adjacente. O que obviamente não seria interessante é o domínio conhecer algo da application, o que não é o caso.
PS: Não estou entrando no mérito de façades pq acho que não é o ponto.[/quote]
O ponto onde você atacou era duplicar os objetos Gustavo, e não criar uma façade de serviço, por isso minha observação acima.
Utilizar ServiceLayer ou não, não diz coisa alguma quanto a isso.
[color=olive] [outro-assunto-que-vc-tocou][/color]Além de tudo,existem muitas outras formas de se fazer controle transacional do que utilizar Service Layer, se você ja utilizou controle transacional otimista + Open Session In View, sabe do que estou falando. [color=olive] [/outro-assunto-que-vc-tocou][/color]
Comentamos varias coisas, mas tem duas questões principais:
1 - Melhor forma de proteger a implementação de um componente de negócio - para controlar o acoplamento - que acaba influenciando como/se objeto de negócio vai parar na camada de apresentação. (soluções discutidas: interfaces para objetos de negócio ou objetos burros).
2 - Operações de negócio devem ser chamadas apenas atrás de uma API “Service Layer”, considerando uma aplicação complexa ou CBD.
Desculpe, mas o que tenho postado até aqui não tem nada haver com ServiceLayer, tem haver com sua solução na duplicação de objetos como solução para não vazer “regras”. Se vc discutia outra coisa, que só ficou clara no ultimo post, não era comigo.
Estávamos no mesmo assunto, duplicação de objetos (objetos burros) como solução para não vazar “regras”, mas em contextos diferentes. Na próxima vez vou especificar melhor, desculpa.
alguma solucao pratica para o problema? Mapear com interfaces quando necessario? Como mapearia o meu MB?
Acho que não entendi esse comentário.
As soluções apresentadas neste tópico são bem práticas. Receita de bolo não existe, você ode procurar as referências dadas aqui e descobrir o que é melhor no seu caso.
mas ainda terá duplicidades dos campos no mapeamento no MB
O que tera (qual estrategia) e por quê?
um cadastro de Cliente por exemplo…
Classe de Dominio anotada como uma Entidade JPA
@Entity
public class Cliente {
private int codigo;
private String nome;
// gets e sets
public int geraPedido(Pedido) {
// Regras
}
}Na tela teria um cadastro de cliente, como mapearia isso no meu MB?
eu crio um atributo cliente no managed bean e uso os atributos da propria classe nas páginas.
ex:
public class ClienteBean {
private Cliente cliente;
// gets e sets
}
jsp:
<h:inputText value="#{clienteBean.cliente.nome}"/>
não sei se é a maneira mais correta e gostaria de opiniões tb!
legal a ideia!!!
mas no jsp eu poderia chamar o meu metodo geraPedido (ai concordo que a discuções das 5 páginas completam a ideia) Nesse caso seria melhor uma interface ou outra classe?
[quote=rob1980a]legal a ideia!!!
mas no jsp eu poderia chamar o meu metodo geraPedido (ai concordo que a discuções das 5 páginas completam a ideia) Nesse caso seria melhor uma interface ou outra classe?[/quote]
A pergunta é: Por que você chamaria esse método? A não ser que sejam pessoas diferentes que codificam Dominio e Apresentação e essas pessoas estejam distantes, não vejo nem muita necessidade em criar uma interface. Na realidade mais comum todos podem mecher em qualquer parte do código e vão saber que esse tal método (que eu nem sei o que ele faz) pode ou não ser chamado na apresentação.
No caso de você precisar estabelecer uma API (como já foi dito por outras pessoas aqui nessa thread) com algum cliente, ai sim pode-se pensar em interfaces, DTOs (em caso de acessos remotos), etc. Considerando que seu Domínio é daquele sistema apenas, você não terá muita necessidade disso.
[quote=Emerson Macedo][quote=rob1980a]legal a ideia!!!
mas no jsp eu poderia chamar o meu metodo geraPedido (ai concordo que a discuções das 5 páginas completam a ideia) Nesse caso seria melhor uma interface ou outra classe?[/quote]
A pergunta é: Por que você chamaria esse método? A não ser que sejam pessoas diferentes que codificam Dominio e Apresentação e essas pessoas estejam distantes, não vejo nem muita necessidade em criar uma interface. Na realidade mais comum todos podem mecher em qualquer parte do código e vão saber que esse tal método (que eu nem sei o que ele faz) pode ou não ser chamado na apresentação.
No caso de você precisar estabelecer uma API (como já foi dito por outras pessoas aqui nessa thread) com algum cliente, ai sim pode-se pensar em interfaces, DTOs (em caso de acessos remotos), etc. Considerando que seu Domínio é daquele sistema apenas, você não terá muita necessidade disso.[/quote]
legal, interessante a ideia…vlw