Vou explicar primeiro a situação para que entendam a minha dúvida.
Eu trabalhei em uma empresa que aplicava o MVC da seguinte forma:
JSP repassa informações para as Actions (Struts), que funcionavam praticamente somente como validador de campos, e em seguida repassava as informações necessárias para a camada de modelo para aplicar as regras de negócio. Na camada de modelo costumávamos usar uma interface chamada de “PESSOAFACADE” que era implementada por uma classe concreta “PESSOAFACADEBEAN”. Todos os códigos da Regra de Negócio ficavam dentro do FACADEBEAN. Já pesquisei e vi que usávamos o padrão facade de forma incorreta já que cada entidade do sistema possuia um FACADE.
A minha dúvida é: A camada onde ficam as Actions(controle) são responsáveis por aplicar as regras de negócio ou devo mesmo repassá-las para outra classe? No caso o controle ficaria somente como um “validador” de campos.
As actions na verdade funcionam como controllers que recebem requisições, que geralmente são direcionadas para uma camada de negócio ou dados.
Um facade é responsável por criar uma “fachada” para que a complexidade da classe a ser utilizada seja simplifcada e seja possível obter uma interface para o acesso.
Ao utilizar um framework, a validação pode ficar a cargo do próprio framework que deve possuir um suporte a validação através de XML ou alguma outra solução.
O que pode ser feito é as actions chamarem o facade que possuem os métodos de negócio e dessa forma excluir qualquer lógica de negócio das actions.
Sim, porque vc teria um facade para cada objeto de negocio, o cara que vai utilizar esse seu modelo teria que saber qual facade invocar e como usar ele para realizar uma tarefa, ou seja, da na mesma que ele invocar direto o objeto de negocio.
Por exemplo, vc tem N objetos de negocio no seu modelo, o utilizador quer executar uma tarefa que precisa iteragir com um número X desses objetos, isso é complexo para ele, saber como lidar com esse número X de objetos, as ordens de chamada, se acessar base de dados controlar a transacao, etc se vc tem um facade para cada um dos N objetos, a complexidade dele vai continuar igual, pois os métodos (interface) que seus facades disponibiliza-ra, sera a mesma que seus objetos de negocio, ou seja, continuou complexo. Para não acontecer isso, vc cria uma interface (facade) que descreva essa tarefa que ele quer executar, e cabe a implementação dessa interface lidar com o numero X de objetos de negocio, então para o utilizador, ele só precisa saber que vai chamar o método do facade que esse metodo se encarrega de lidar com seus complexos objetos de negocio e executar a tarefa.
Para entender melhor, da uma olhada na estrutura do exemplo de facade do wikipedia:
repare que o cara quer fazer alguma coisa (doSomething), para fazer isso ele tem que lidar com 3 classes em 3 pacotes separados, invocando metodos de uma certa forma e ordem. Se cada uma dessas 3 classes tivessem um facade, vc naum facilitaria a vida do cliente que esta usando. Por isso vc cria um facade que vai ser responsavel por fazer essa coisa (doSomething) e ele se encarrega de esconder essa complexidade do cliente.
O que geralmente vc pode fazer eh criar um facade para cada modulo do seu sistema, por exemplo o facade do modulo de pedidos, o facade do modulo de contas a pagar, o facade do modulo de estoque, etc onde cada facade realiza as funcionalidades de cada modulo iteragindo com os objetos de negocio do mesmo.
Então o Facade seria usado para evitar que vc instancie um balde de classes e invoque outro balde de m´petodos. Ele concentra uma função dentro de uma classe separada, O FACADE.