E tem gente que questiona porque cosntruir um Domain Model e uma camada de negócios consistente é importante. Leia o post no Portal Java e você vai ver um problema bem interessante.
No caso específico, alguém implementou regras de negócio em Actions Struts. Muito bom, exceto pelo fato que isso gera:
- Acoplamento exacerbado ao framework e consequentemente ao HTTP
- Programação altamente procedural (qual a diferença entre uma Action e uma função?)
Não, escolher outro framework não é a solução (mesmo que seja o Spring). O importante é saber que estas regras devem estar separadas em sua própria camada, modeladas através de objetos de negócio.
Bom, esse caso específico pede uma medida imediata que evite reescrever a lógica da aplicação toda novamente. Uma soluções é usar adaptadores.
Se você tem uma AdicionarUsuarioAction, uma RemoverUsuarioAction, por exemplo, pode criar uma interface assim:
public interface GerenciadorUsuario{
public adicionar(Usuario u);
public remover(Usuario u);
}
Todo código novo do seu sistema deve usar essa interface. O próximo passo é criar um Adapter para suas Actions, e isso mostra o que o acoplamento faz por você:
public GerenciadorUsuarioAdapter{
public void adicionar(Usuario u){
RequestAdapter req = new RequestAdapter();
requestAdapter.setParameter(”login”, usuario.getLogin());
ResponseAdapter resp = new ResponseAdapter();
executarAction(AdicionarUsuario.class, req, resp);
}
}
Uma bela gambiarra. Request e ResponseAdapter são implementações do HTTP request e HTTP response. executarAction(Class, HttpRequest, HttpResponse) faz a chamada à Action emulando um ambiente web.
A melhor solução, claro, continua sendo refatroar o código e remover a lógica de negócios do Struts. Não, não adianta colcoar esta no WebWork, XWork, Spring… o que importa é colocá-la em um Domain Model consistente e reaproveitável, mas Domain Model é assunto apra outro post.
