Ha algum tempo atrás discuti neste blog sobre com o MVC não representa separação em camadas.

Um conceito complexo, e ao que parece, embora felizmente tem ainda quem entende lógica para saber a diferença , ainda ha muitos que não sabem.

Então decidi esclarecer um pouco melhor a diferença, em certa medida a causa, de porque tanta confusão. O porquê de tanta confusão é que existe um padrão muito parecido com o MVC mas que realmente têm que ver com camadas: O Entity-Control-Boundary. Em muitos lugares você vai ver as pessoas dizendo que o ECB é relacionado ao MVC de alguma forma [1] [2] o que não é verdade. Obviamente. Este é um caso de falsos gémeos.

O conceito do ECB é diferente do MVC no que tange à arquitetura, mas muito semelhante no que tange às responsabilidades. “Entity” representa a entidade. A “entidade” é um elemento prevalente, ou seja, ele existe mesmo quando o sistema está desligado. A entidade é normalmente persistente ou de alguma forma serializada em algum arquivo em algum lugar. A entidade representa estado, memória, conhecimento, e por isso é fácil entender porque ela deve ser/é persistente. “Control” representa o elemento que faz algo. Algoritmos, decisões e lógicas de diferentes tipos são feitas no âmbito do control. Não se trata de delegar e depois redirecional como no control do MVC, mas sim fazer algo. Decidir. “Boundary” representa a “fronteira”. O conceito de fronteira não tem que ver com apresentação, como a view, tem que ver com adaptação de impedância. Ou seja,
estabelecer uma comunicação entre o “mundo” e o control.

O padrão ECB é estabelecido na UML como uma forma genérica de representação destas três partes que se relacional ao básico de todos os programas
Input, Output, Processamento, Estados. Repare que os dados não fazem parte deste processo e são sempre transientes. Ou seja, apenas as entidades são persistidas e não
todo e qualquer objeto de dados que decidirmos criar. O control representa o processamento, a entidade o estado e o Input/Output a Fronteira.

O padrão Entidade-Controle-Fronteira é mais geral, genérico e de propósito e aplicação mais gerais que o MVC. O ECB é um padrão de arquitetura e o MVC de design. São de famílias diferentes.Lembrando que o MVC se restringe apenas a um andar que normalmente é o andar de apresentação. O ECB é usado para desenhar as funcionalidades como um todo e é especialmente util na tradução de casos de usos
e fluxo de interação.

A Fronteira (“Boundary”) é normalmente construída por um conjunto de classes, não apenas uma e representa uma responsabilidade macro e não uma responsabilidade
individual. É por isso que em UML não usado o simbolo de classe, mas um simbolo especial próprio.
Em sistemas web a fronteira seria o web contêiner inteiro. Em sistemas desktop seria todo o maquinário Swing com respetivos listeners e actions. Dito de outra forma
O MVC está dentro da Fronteira e é normalmente usado para realizá-la quando o usuário é um humano. Quando o usuário é outro sistema, a Fronteira se transforma
num mecanismo  semelhante a um serviço e menos MVC. Web services (SOAP ou REST) caem nesta categoria. Adaptadores como conectores a ESB também podem estar na fronteira.
Se pegarmos, por exemplo, a implementação de um driver JDBC a fronteira é toda a API JDBC com que o usuário pode interagir.

Da mesma forma, o Controle também é um conjunto de classes e não necessariamente uma classe apenas. Não é o mesmo que o Controlador do MVC. As classes de Controle
têm a responsabilidade de definir regras. Normalmente de negocio. Padrões uteis para implementar o Controle são Service, Validator, Specification, Strategy, Template Method e outros na linha de padrões relacionados
a algoritmos e controle. O Controle não realizações ações de direcionamento, isso é papel da Fronteira (“Bondary”), o que o Controle faz é decidir e realizar, normalmente isso significa manipular as entidades para criar ou modificar o estado.

As entidades são elementos passivos que são manipulados pelo Controle. Estes elementos são objetos que de alguma forma são persistidos. As classes de persistencia
como DAO , DomainStore e afins não fazem parte da entity. Podem fazer parte do controle ou serem consideradas classes auxiliares, mas não são conceitos do padrão ECB.

ECB e EJB

É interessante comparar o padrão ECB com o padrão tecnologico Enterprise Java Beans. O conceito do EJB é alicerçado em três tipos principais de objetos
Entity Beans, Session Beans e Message Beans. Onde os Session Beans podem se dividir em Statefull e Stateless. O padrão dos Session Beans e Message Beans é dividido em
contrato (interface java) e implementação (classe java). O padrão EJB com certeza não é a implementação do padrão MVC mas pode ser considerado uma implementação inspirada pelo ECB.
A Fronteira são as interfaces dos session e as filas associadas aos Message Beans. Esta é a parte “publica” que pode ser chamada por outros sistemas.
Todas a infraestrutura que realiza estas interfacess de forma a prover mecanismos remotos/ serialização que está contida no EJB container e é realizada pelo provedor do container que canaliza as chamadas para a implementação.
As implementações dos objetos Session e Message Beans correspondem com a implementação do Controle. Os objetos Entity Beans no padrão antes do EJB 3.0 tinham duas funções: a de representar o estado,
e a de representar as pesquisas sobre o estado. Atualmente esta responsabilidade é separa entre os POJO que são o estado e os métodos de pesquisa do DomainStore que permite consultar
este estado. O padrão EJB é um uso direto do padrão ECB.

ECB e Camadas

Como falei, cada parte do ECB representa um conjunto de objetos que trabalham junto para um fim. O nome de que se dá a este conjunto de objetos é : Camada.
Camada é também usado como sinónimo de Andar que além de representar um conjunto de camadas representa um elemento de uma estrutura de pilha. Quando falamos de “Uma camada em cima da outra” fazendo alusão Às camadas de um bolo estamos abusando da linguagem e da metáfora.
A metáfora correta é a de andares uns em cima de outros e “camada” é apenas o nome de um conjunto de classes que colabora para um fim.
As classes do ECB além de formarem camadas podem também formar andares já que a comunicação só se dá em uma direção entre as partes: B->C->E.  Esta é a comunicação
que esperamos entre camadas.

ECB e MVC

O padrão MVC pode ser escrito usando o padrão ECB?  O ECB é um padrão arquitetural de responsabilidade e o MVC é um padrão de design também baseado em responsabilidade. A diferença parece minima.

A diferença é muito grande e muito maior do que parece. Além dos dois padrões não se referirem às mesmas responsabilidade e sim a responsabilidades diferentes que infelizmente têm nomes muito parecidos

No padrão ECB a dependencia dos elementos é sequencial. O Controle não invoca a Fronteira nem a entidade invoca o Controle. No padrão não apenas o Model pode invocar o Controlador, como deve, assim o como o controlador deve invocar a View. A dependência dos elementos do MVC é um triangulo o ECB não. A analogia seria que o MVC é como os 3 poderes da politica em que cada um comunica com o outro e os 3 alcançam um objetivo, enquanto que o ECB é um padrão mais hierárquico em que, quem está em baixo é comandado por quem está em cima. Isto faz o ECB um mecanismo muito próximo do conceito de camada em pilha que o MVC nunca poderá ser devido às sua simetria triangular.

O MVC não pode ser escrito como sendo um caso do ECB. Sim, muitos sites e autores tentarão vender isso para você do mesmo jeito que tentam vender que MVC é arquitetura por camadas. Espero que este post deixe claro que isso simplesmente não faz sentido nenhum. É como dizer que uma cebola é uma maçã apenas porque ambas são redondas.

O que sim acontece é que cada elemento do ECB é a coordenação de város objetos e  o MVC é um ótimo padrão para criar essa coordenação, especialmente na camada de Fronteira.

ECB e os 5 Andares

Em um sistema básico você vê claramente estas três camadas do ECB, mas em sistema mais completos você verá camadas adicionais. No modelo de 5 andares, por exemplo (Cliente, Apresentação, Domínio, Integração, Recursos” ), não existe uma única aplicação do padrão ECB mas três.

A primeira aplicação do ECB serve para controlar o motor de interação com o usuário. A segunda para controlar as regras do sistema/ negócio e a terceira para controlar as regras de dados e integração com outros sistemas fornecedores. No padrão de 5 andares , cada andar tem mais do que uma responsabilidade sob perspectivas diferentes. Os andares das pontas são os mais simples, sendo o andar de domínio o mais recheado de responsabilidade. Claro que é ai onde o “coração” do sistema existe.

O andar cliente – por exemplo um browser ou um applet – representa apenas uma Fronteira, normalmente implementada em MVC quando o usuário é um Humano.
A apresentação – o mecanismo de fluxo no web contêiner, por exemplo, normalmente em algo como Spring MVC ou JSF também tem responsabilidades de
fronteira e por isso o padrão MVC é comun ser usado. Contudo este andar também toma decisões que não são apenas de fluxo e apresentação. Algumas validações especiais e outras interações que deixam a interatividade maior, têm que corresponder com as regras do sistema/negocio e precisam ser controladas.É por isso que o objeto de control do MVC – o Controlador – assume também o papel de implementação do Controle, embora o padrão BusinessDelegate possa ser usado para diferenciar as duas responsabilidades. Por exemplo, no struts, uma action (controlador do MVC) pode chamar um outro objeto BusinessDelegate que contém apenas regras de negocio e portanto cumpre o papel do Controle do ECB.
Do outro lado temos o andar de Recursos. Recursos são dados persistidos em muito formatos (normalmente arquivo e banco de dados) e não ha mais nada aqui do isto: dados burros gravados em algum lugar em algum formato.
O andar de Integração detêm o papel de controle para “dados” o que significa toda a estrutura de JDBC, comunicação , DAO/DomainStore e inclusive triggers.
O papel entidade é representado pelos objetos que são enviados para persistência. A Entidade que representa o estado é a entidade do andar de Resources, a entidade do andar de integração é um (D)TO.
Hoje em dias os frameworks como o hibernate escondem a diferença de você, mas quem trabalhou com EJB pré 2.0 sabe que o uso de DTOs era comum e que o DTO não era a Entidade ( normalmente o DTO navegava entre os andares e o Entidade apenas existia no EJB Container)
E sobra o andar de domínio, também chamado de andar de negócio. Repare que este andar o padrão ECB está representado por completo, mas de diferentes fases.
A Entidade vida da fase de apresentação é normalmente um objeto no padrão DTO que foi tratado pela apresentação e agora é lançado para o dominio tratar. Aqui também ,as tecnologias modernas
deixam que você utilize o mesmo objeto que você usa para persistencia de estado. Isto é bom para reduzir o numero de classes, mas conceptualmente
o mesmo objeto cumpre responsabilidades diferentes em cada andar. A Fronteira do Domínio nada mais é que a interface do DomainStore ou do DAO que permite comunicar com “a parte de baixo” do sistema.
O controle do andar de domínio é controle de fato onde estão as regras. Isto normalmente é feito construindo objetos no padrão service que se comunicam com outros services e com objetos no padrão Repository para encontrar entidades num certo estado.

Repare como o andar de Domínio é onde tudo se funde e onde a decisão realmente irá provocar efeitos no estado do sistema.

Resumo

O padrão ECB é um padrão de Arquitetura com mais usos que o MVC e não limitado a uma camada. Aliás ele é o padrão por detrás do conceito antigo de servidores em 3 camadas.
Mas também é o padrão por detrás de qualquer outro numero de camadas. A arquitetura em 5 camadas deriva também do padrão ECB e até podemos usar o padrão ECB para provar que todas as arquiteturas terão um numero de andares impar (1 – quando tudo está num andar só. É uma confusão, mas era assim no passado , 3 – quando temos UI e dados um pouco separados do resto , 5 – quando temos a UI e os recursos completamente desacoplados …)
Porque o padrão ECB se assemelha muito ao MVC e as pessoas estão habituadas a arquitetura em 3 camadas (andares) tudo parece se misturar. Mas se pensarmos em arquitetura de 5 camadas é fácil ver onde cada padrão é usado e porque e como eles são diferentes.

Espero com isto ter ajudado a remover qualquer dúvida sobre o assunto de MVC e camadas provendo ao mesmo tempo um novo padrão para que você possa desenhar sua arquitetura.