MVC – Onde e Como 

May/11
23

Quem est√° seguindo deve saber da conversa que estava acontecendo no post sobre MVC e Camadas onde se falava sobre a “localiza√ß√£o” , ou melhor, se o Modelo pertence na camada de business ou n√£o.

Em primeiro lugar vamos clarificar o que significa estar ou n√£o na camada de business. Podemos entender “estar na camada de business” como estar no andar “business” ou dominio. Ora o andar de dominio vem a seguir ao de apresenta√ß√£o e antes da integra√ß√£o. √Č o andar central de uma arquitetura em ¬†5 andares.
Ou podemos entender “camada business” como “o pacote das classes do andar de business” ou seja, em qual pacote ou sub-pacote estaria a classe.

A seguir mostro o esquema classico do MVC

MVC_1Normalmente quando usamos o padr√£o MVC estamos interessados em dar alguma margem ao programador final de poder implementar varia√ß√Ķes do modelo ou da view de uma forma intercambi√°vel, como menos ou mais facilidade tecnologica – isso n√£o est√° em causa agora. Contudo o controller est√° sempre o dominio de quem implmentou o MVC. O prop√≥sito e objetivo final da estrutura est√° no Controller e normalmente ele √©¬†inalter√°vel. Em alguns casos pode ser configur√°vel ou extensivel mas nunca √© possivel mofici√°-lo por completo. O Controller √© onde existe a raz√£o de ser do MVC.

A View e o Model , s√£o , portanto, normalmente n√£o implementados, ou implementados em vers√Ķes b√°sicas. Por exemplo, a view √© normalmente implementada numa vers√£o simples j√° que sem ela n√£o haveria funcionalidade nenhuma. Por exemplo, no swing a view √© o look & feel e sempre existe um que funciona ( o look and feel padr√£o da JVM). Por exemplo, no Apache pivot √© implementa uma view padr√£o, no JSF temos a implementa√ß√£o de referencia. Uma exce√ß√£o a esta regra seria por exemplo o struts, onde a view ser√£o as JSP criadas pelo programador.

Portanto um diagrama que leva em conta as implementa√ß√Ķes seria mais ou menos assim:

MVC_2

Estas implementa√ß√Ķes s√£o classes java ou se traduzem em classes java e pertencem em algum pacote/ camada/ andar. Como disse no outro post o MVC √© um padr√£o que se aplica em √ļnica camada, ent√£o por¬†consequ√™ncia¬†das tudo est√° no mesmo andar que √© o de apresenta√ß√£o ( supondo que estamos usando o MVC nesse andar, onde √© mais comum).

Mas peguemos o exemplo do JSF em que o model √© um managed bean. Em tese o managed bean pertence na camada de apresenta√ß√£o e ele cont√©m regras relacionadas √† apresenta√ß√£o. A chamada “l√≥gica de tela”. Mas √© possivel, por exemplo, usar um EJB Session Bean para fazer o papel do manged bean. E agora , em qual camada pertence ? Esta √© a ess√™ncia da conversa discutida no outro post.

Existe aqui uma pequena falacia de confundir tecnologias com camadas/andares e assumir que o EJB pertence na camada de negocio. O que não é verdade.Se usarmos EJB como porta de entrada e webservices ou message beans estamos usando na camada de integração, mas não vamos prender nisto que não interessa agora. Vamos assumir que o EJB é a nossa implementação do andar de business. Ora, ou usar também como managed bean não estamos misturandos as coisas ? Sim estamos. E o fazemos para facilidade prática.

Estamos fundindo duas partes , duas camadas e tornando-a “uma” sem costuras ( seamlessly – dai o JBoss Seam que faz exactamente isto).

Mas l√° porque as estamos fundindo tecnicamente, n√£o significa que n√£o uma separa√ß√£o entre as duas. √Č como dizer que o ombro √© o mesmo que a cabe√ßa porque entre eles existe um pesco√ßo que os une “sem costuras”. Mesmo sendo unidos podemos identificar as v√°rias partes.

O MVC usado no JSF continua usando como managed bean um objeto java que √© o que ele exige, o fato desse objeto java ser tambem um EJB √© mera¬†coincid√™ncia. Por outro lado o negocio est√° definido no EJB e o fato dele tamb√©m um managed bean √© mera coincidencia. O objeto pertence nas duas camadas simultaneamente. Isto √© possivel ? sim, e est√° o seam ai para provar, mas isso n√£o significa que seja algo desej√°vel ou seja boa arquitetura. Mas funciona e √© “simples”. Porque n√£o √© bom ? Ora, porque est√° acoplado. O principio de separa√ß√£o de repsonsabilida deixa claro que um objeto deve ter apenas uma responsabilidade. Ser de duas camadas obviamente √© ter mais do que uma responsabilidade.

Bom, então o managed bean, não importa como é implementado pertence no andar/ camada de apresentação ,porque o MVC onde ele é usado pertence nessa camada/andar. Mas isto é válido para todos os modelos de MVC ?

Um outro ponto √© discuss√£o √© a interface / contrato do modelo. Por exemplo, no JSF se exige um objeto com caracteristicas de bean. No swing se exisge que implemente uma certa interface java. Ou seja, sempre o controller tem uma forma de “ler” o modelo ou intrpretar certa informa√ß√£o como sendo o modelo. Essa forma de leitura √© o contrato. O contrato √© aquilo que se espera do objeto para que controller possa comunicar com ele. Este contrato, seja implicito ou explicito na forma de uma interface java ou uma classe abstrata sempre pertence no andar da apresenta√ß√£o.

Como eu implementaria uma interface sem que o objeto que a implementa estivesse na mesma camada ? Existem formas para isso ?

Sim, existem. A mais simples é o padrão Proxy, mas no caso do java este exige algum tipo de interface fisica. Um contrato conceptual não é suficiente.
Mas temos o padrão bridge que vai mais além e permite o desacoplamento entre a implementação e contrato de uso. O JDBC é todo baseado nisto. Ha uma definição rigorosa de como o driver dever responder, mas não como. Ou seja, o vendedor de bando de dados pode implementar o driver como quiser remoto ou local, como quiser, mas ele tem que responder às interfaces e contratos JDBC tal como explicitado na especificação JDBC. Tudo bem, que o JDBC não tem nada que ver com MVC, mas estamos de implementar uma interface de forma que a implementação fique em outra camada. Na maioria dos casos é incomum e até inutil usar uma camada diferente para a implementação é mais mais facil usar um adapter ou um business delegator, mas a tecnologia não nos impede de separar.

Portanto, no caso geral a implementa√ß√£o pode estar em outra camada, embora isso n√£o seja nada comum ou √ļtil. O Seam √© uma tecnologia onde isso se torna comum e at√© quase que padr√£o, contudo isso limita , e muito, a evolu√ß√£o do sistema j√° que o Seam viola alguns principios basicos em nome da velocidade de desenvolvimento. Isto √© bom no primeiro dia, mas pode ser um pesadelo no ultimo.

O model √© onde o programador d√° “inteligencia” a um robot autom√°tico que √© o controlador. Essa inteligencia tende a mudar muito ao longo da vida do software e portanto n√£o √© bom misturar com outras coisas. Se quiserem de uma forma bem simples de memorizar :¬†l√≥gica¬†de tela n√£o se mistura com l√≥gica de negocio. N√£o s√£o a mesma coisa.

Espero que tenha esclarecido algo.

Um comentário para “MVC – Onde e Como”

  1. Muito boa complementação da conversa do outro post.

Comente

Artigos