Fragmental

6/17/2005

Regras são Regras

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:
  1. Acoplamento exacerbado ao framework e consequentemente ao HTTP
  2. 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.


 
f