Alguém utiliza o pattern Delegate junto ao Struts? Eu o utilizo para algumas coisas, mas tenho dúvidas. Ela me permite a fácil substituição da camada de apresentação, por exemplo, trocar o Struts pelo JSF. Bom. A minha dúvida é a seguinte: Todas a minha lógica de negócio deverá estar dentro da Delegate? É esta a finalidade da Delegate?
Eai,
Eu uso um delegate como entrada pro meu modelo de dominio. A camada web só acessa esse delegate e ele que desencadeia as operações que ocorrem dentro da camada de negocio.
Tem funcionado bem aqui, e realmente fica facil de implementar duas camadas de visualização diferentes (seja struts + swing ou qq outra).
Eu estou usando JSF e as actions dos meus beans usam este delegate para acessar o dominio.
[]s
Ferry
Olá,
Pelo que eu conheço o pattern BusinessDelegate é utilizado para fazer a interface entre o cliente(actions de JSP, etc0 e a regra de negócio da aplicação(RULE). Em outras palavras, ele serve pra delegar em qual Manager será tratada tal situação da aplicação.
Usando EJB, o delegate serve também para axar estes objetos e para definir qual o tipo de protocolo que deve ser usado para esta comunicação.
Portanto, por definição, o Delegate não deve conter lógica, apenas delegar para a regra correta 
Obrigado pela atenção ao assunto pessoal. Tenho visto alguns analistas implementarem sistema usando técnicas conforme o próprio entendimento. Então achei que neste fórum poderia obter maiores informações sobre esta questão.
Na site da sun (Core J2EE Design Patterns) há um foco muito forte em EJB. Não utilizo EJB e conheço poucos que o utilizam. Mas isto é apenas uma experiência própria. Não estou desmerecendo tal tecnologia.
Bom. Gostaria de perguntar mais uma coisa, para ficar mais claro o entendimento.
No caso da lógica não ficar na Delegate ela ficaria onde? Numa Facade?
Detalhando um pouco mais o modelo que utilizo:
Cliente -> Action -> Delegate(Lógica de Negócio) -> Facade (Serviço) -> DAO
Vocês têm algumas sugestão ou crítica quanto a este modelo que utilizo.
fbar,
Nesse seu modelo eu adicionaria mais uma camada entre o Facade e o DAO, que seria uma camada chamada Manager. É nela que ficaria a regra de negócio da aplicação, os métodos que trabalhariam diretamente com o DAO.
Cliente -> Action -> Delegate -> Facade -> Rule(Manager) -> DAO
Delegate -> responsável por achar os facades e delegar as requisições do Cliente
Facade -> Camada que conversa diretamente com o Rule e sendo um ejb pode ser acessada remotamente.
Rule -> Camada onde fica a lógica de toda aplicação. Validações de lógicas de dados, etc. Chamadas das operações save, delete, etc do DAO.
DAO -> Camada de abstração da manipulação dos dados (save, delete, etc)
leonickel,
Desculpe a ignorância, mas este Manager é um design pattern? Nesse caso, onde encontro material sobre ele?
Aproveito para detalhar mais o modelo que utiliza. É claro que certas coisas estão implícitas, mas acho que vale a pena.
Cliente HTTP -> Action -> Delegate -> Facade -> Rule(Manager) -> DAO -> Impl. DAO -> Banco de dados
Ola fbar,
Cara recomendo que vc leia o livro Domain-driven-design do eric evans. O que faltou na sua arquitetura foi o principal, que é o modelo de dominio. O modelo de dominio é aonde conterá a lógica que é capaz de resolver o problema que o seu sistema se propoe a resolver.
O leonickel está chamando a camada de dominio de manager, acredito que a idéia não é bem essa. O que vc precisa nao é um lugar pra conter logica, vc precisa é de uma abstração do ambiente em que o sistema irá atuar. Isso é o que a OO e Domain Driven Design propõe.
Existe um livro que é um “resumo” do domain driven design. Só de ler ele suas idéias devem clarear.
Este livro é free e é rapidinho de ler, eu nao demorei nem 2 dias.
taqui o link pro livro.
http://www.infoq.com/minibooks/domain-driven-design-quickly
Espero que isso te ajude.
Abraço
Ferry