Arquivo Discussoes de Programacao e Tecnologia Pessoal,
eu tava querendo modelar meu sistema usando “Fluent Interface”, porém, como a minha interface será um session bean stateless, fico pensando se isso é viável, pq em tese, para cada chamada ao método eu vou gerar uma requisição no servidor, então seria melhorar fazer:
Transferencia(contaA, contaB, valor)
do que
Transfere.da(contaA).para(contaB).valor(valor)
O que vcs acham?
com certeza né filhote!
Se você fizer Transfere.da(contaA).para(contaB).valor(valor) beleza… só não conte pra ninguem, hauahahua, bem… pelo menos pra mim, hahaha.
1º Para fazer essa sua coisa bi-i-ta, teria que ser Statefull e não mais Stateless (mais rápido do que dizer “grande buraco negro” seu servidor - obviamente depende de qual e das requisições - será pedindo água).
2º Como ficaria a codificação na classe?? todos esses métodos seriam setter ( na prática, não na convenção da assinatura ), e no método “void valor(…” é que você iria sub-entender que quando alguem informa o valor, quer dizer que ela já informou a conta, origem e está querendo na verdade é enviar o processo??? o loko…
Mas enfim, só respondendo a pergunta, rsrsrs, sim a primeira opção é melhor, cuidado pra não exagerar Fluent Interface meu caro, fica uma codificação bem legivel/clara, mas o desempenho vai lá pras cuicas se usado em excesso.
Falows
Você faz métodos de EJB da maneira tradicional. Daí crie uma classe (normal, não-EJB) que seja uma interface fluente, onde todos os métodos apenas armazena valores nos atributos. Apenas no último método (no seu caso, valor()), você chama o método EJB com todos os atributos guardados anteriormente.
EJB é pouco flexível. Pra qualquer coisa diferente, tipo DDD ou interface fluente, deve-se criar uma camada local por cima.
Uma coisa me assusta: por que você chamou a variável de “Transfere”, ao invés de “transfere”? Você não tá querendo deixar tudo static, né?
Você faz métodos de EJB da maneira tradicional. Daí crie uma classe (normal, não-EJB) que seja uma interface fluente, onde todos os métodos apenas armazena valores nos atributos. Apenas no último método (no seu caso, valor()), você chama o método EJB com todos os atributos guardados anteriormente.EJB é pouco flexível. Pra qualquer coisa diferente, tipo DDD ou interface fluente, deve-se criar uma camada local por cima.
Uma coisa me assusta: por que você chamou a variável de “Transfere”, ao invés de “transfere”? Você não tá querendo deixar tudo static, né?
Ola Leonardo,
obrigado pela resposta.
O Transfere com T maiusculo foi um descuido, pois eu digitei esse código ficticio aqui no guj para exemplificar só, não tá tudo static não! 
Eu só estou na parte de idéias ainda. Tbm imaginei que com EJB seria inviável usar Fluent Interface. Só coloquei a questão pra ver o que o pessoal tem feito mesmo em relação a isso.
[]'s
Me agrada também mais a idéia de ter a sua Fluent Interface numa camada abaixo do EJB(Ou outros tipos de Service Layer).