Arquitetura ECB e o Mist√©rio do MVC em Camadas 

Feb/12
13

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.

 

2 comentários para “Arquitetura ECB e o Mist√©rio do MVC em Camadas”

  1. Parabéns pelo artigo!
    Compreendi melhor como o padr√£o funciona.

    Muito obrigado.

  2. […] Este assunto se mostrou muito mais debatido do que esperava o que me levou a escrever outros posts sobre o tema. Para entender melhor e mais profundamente este tema sugiro que leia estes outros posts : MVC-Onde e Como e Arquitetura ECB […]

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos