O c\u00f3digo de aplicativo complexo escrito sem os padr\u00f5es MV* \u00e9 dif\u00edcil de testar, reutilizar e manter. Os padr\u00f5es eliminam ou enfraquecem a conex\u00e3o entre a visualiza\u00e7\u00e3o, o modelo e o controlador, separam o c\u00f3digo e simplificam o desenvolvimento. Abordaremos os tipos de padr\u00f5es MV* e seu uso no SimpleOne.<\/p>\n
Ao desenvolver um aplicativo SimpleOne, projetamos cuidadosamente a interface do usu\u00e1rio (UI) e a experi\u00eancia do usu\u00e1rio (UX) para facilitar e tornar conveniente o uso da plataforma pelos nossos clientes. Mas a UI \u00e9 apenas a ponta do iceberg vista pelo usu\u00e1rio (User). Por tr\u00e1s dos bot\u00f5es e campos est\u00e1 o c\u00f3digo que deve ser dimension\u00e1vel, sustent\u00e1vel e confi\u00e1vel. Para resolver esses problemas, os desenvolvedores aplicam os padr\u00f5es MV*, que s\u00e3o usados para separar o c\u00f3digo da interface do usu\u00e1rio, a l\u00f3gica e o processamento de dados.<\/p>\n
Vamos imaginar um aplicativo que tenha um formul\u00e1rio com v\u00e1rios elementos e widgets. O c\u00f3digo desse formul\u00e1rio cont\u00e9m tanto a descri\u00e7\u00e3o da l\u00f3gica quanto o c\u00f3digo dos elementos da interface do usu\u00e1rio, e tamb\u00e9m pode conter fragmentos para processamento de dados. Para um aplicativo simples, o suporte a esse princ\u00edpio de programa\u00e7\u00e3o n\u00e3o \u00e9 um problema. A qualquer momento, voc\u00ea pode encontrar inter-rela\u00e7\u00f5es e fazer altera\u00e7\u00f5es sem quebrar a integridade. Quando o aplicativo se torna mais complexo, o suporte a uma interface escrita sem padr\u00f5es se torna um problema.<\/p>\n
O problema vem da viola\u00e7\u00e3o do princ\u00edpio da responsabilidade \u00fanica (single responsibility principle<\/a>) – “Uma classe deve ter apenas um motivo para ser alterada”. Temos o c\u00f3digo da interface do usu\u00e1rio (View), a l\u00f3gica (Controller) e o processamento de dados (Model) reunidos em uma interface, portanto, h\u00e1 v\u00e1rios motivos para alterar. Quando alteramos o c\u00f3digo de um componente, temos que alterar outros componentes tamb\u00e9m. Isso complica o suporte ao aplicativo, \u00e9 quase imposs\u00edvel realizar testes automatizados e a reutiliza\u00e7\u00e3o do c\u00f3digo \u00e9 muito limitada.<\/p>\n \u00c9 por isso que \u00e9 conveniente e correto usar padr\u00f5es – eles separam o c\u00f3digo da interface do usu\u00e1rio (visualiza\u00e7\u00e3o), o c\u00f3digo da l\u00f3gica (apresentador, controlador, ViewModel e outros) e o c\u00f3digo de processamento de dados (modelo). Podemos alterar facilmente a l\u00f3gica sem alterar a interface do usu\u00e1rio ou fazer altera\u00e7\u00f5es apenas nas rotinas de processamento de dados. Cada padr\u00e3o pode ser testado independentemente dos outros e usado posteriormente em outros aplicativos.<\/p>\n Os padr\u00f5es mais comumente usados s\u00e3o Model-View-Controller<\/a>, Model-View-Presenter<\/a> e Model-View-View-Model<\/a>. Vamos dar uma olhada em como eles diferem e onde se aplicam.<\/p>\n Todos os tr\u00eas padr\u00f5es em considera\u00e7\u00e3o t\u00eam dois componentes recorrentes. Eles diferem em recursos, mas s\u00e3o iguais em sua ess\u00eancia.<\/p>\n A visualiza\u00e7\u00e3o \u00e9 uma interface visual (UI). Ela pode consistir em elementos individuais ou widgets. Exemplos de visualiza\u00e7\u00e3o s\u00e3o o c\u00f3digo de cria\u00e7\u00e3o de formul\u00e1rios no MFC e no WinForms, html no ASP.NET, XAML no WPF e no Silverlight.<\/p>\n Model s\u00e3o os dados do aplicativo que s\u00e3o exibidos usando a interface e o processo de recupera\u00e7\u00e3o e salvamento desses dados.<\/p>\n O padr\u00e3o mais antigo, que foi desenvolvido em 1979 para o desenvolvimento de aplicativos em Smalltalk. Naquela \u00e9poca, n\u00e3o havia o shell gr\u00e1fico do Windows com seus elementos padr\u00e3o. A interface era renderizada manualmente por c\u00f3digo. Entretanto, mesmo naquela \u00e9poca, a separa\u00e7\u00e3o do c\u00f3digo de exibi\u00e7\u00e3o, l\u00f3gica e dados foi uma revolu\u00e7\u00e3o no desenvolvimento.<\/p>\n Nesse padr\u00e3o, vemos tr\u00eas elementos principais:<\/p>\n Vamos descrever o princ\u00edpio do padr\u00e3o MVC da seguinte forma. O controlador processa as a\u00e7\u00f5es do usu\u00e1rio – cliques do mouse, pressionamentos do teclado ou solicita\u00e7\u00f5es http de entrada. O controlador passa as altera\u00e7\u00f5es processadas para o modelo e as desenha na visualiza\u00e7\u00e3o (modo passivo), ou o modelo recebe as altera\u00e7\u00f5es diretamente da visualiza\u00e7\u00e3o (modo ativo). A principal tarefa da visualiza\u00e7\u00e3o \u00e9 renderizar os dados do modelo usando o controlador.<\/p>\n O desenvolvimento da programa\u00e7\u00e3o visual e dos widgets aboliu a renderiza\u00e7\u00e3o de elementos individuais da visualiza\u00e7\u00e3o, de modo que uma classe de controlador separada n\u00e3o \u00e9 mais necess\u00e1ria. Os pr\u00f3prios elementos sabem quais a\u00e7\u00f5es o usu\u00e1rio executa com eles. Mas ainda \u00e9 necess\u00e1rio separar a l\u00f3gica do aplicativo dos dados. Assim, o padr\u00e3o foi substitu\u00eddo por Presenter em vez de Controller.<\/p>\n Em compara\u00e7\u00e3o com o MVC, a fun\u00e7\u00e3o Model n\u00e3o foi alterada, a View agora lida com as a\u00e7\u00f5es do usu\u00e1rio (usando widgets, por exemplo) e, se essa a\u00e7\u00e3o alterar algo na l\u00f3gica da interface, ela ser\u00e1 passada para o Presenter.<\/p>\n A principal tarefa desse padr\u00e3o \u00e9 separar a visualiza\u00e7\u00e3o do controlador para criar visualiza\u00e7\u00f5es intercambi\u00e1veis e poder test\u00e1-las independentemente.<\/p>\n O Presenter, como condutor, \u00e9 respons\u00e1vel pelo trabalho sincronizado do Modelo e da Visualiza\u00e7\u00e3o. Se ele receber uma notifica\u00e7\u00e3o da visualiza\u00e7\u00e3o sobre uma a\u00e7\u00e3o do usu\u00e1rio, atualizar\u00e1 o modelo e sincronizar\u00e1 as altera\u00e7\u00f5es com a visualiza\u00e7\u00e3o. Toda a comunica\u00e7\u00e3o ocorre por meio da interface, o que lhes d\u00e1 separa\u00e7\u00e3o.<\/p>\n O MVC tem duas implementa\u00e7\u00f5es: Visualiza\u00e7\u00e3o passiva, em que a visualiza\u00e7\u00e3o n\u00e3o sabe nada sobre o modelo e o apresentador \u00e9 respons\u00e1vel por obter informa\u00e7\u00f5es do modelo e atualizar a visualiza\u00e7\u00e3o, e Controlador de supervis\u00e3o, em que a visualiza\u00e7\u00e3o sabe sobre o modelo e vincula os dados \u00e0 pr\u00f3pria visualiza\u00e7\u00e3o.<\/p>\n A principal diferen\u00e7a entre esse padr\u00e3o e os outros \u00e9 a presen\u00e7a de vincula\u00e7\u00e3o de dados no WPF e no Silverlight.<\/p>\n Aqui n\u00e3o h\u00e1 comunica\u00e7\u00e3o direta entre ViewModel e View, ela \u00e9 feita por meio de comandos (vincula\u00e7\u00e3o) que consistem em propriedades e m\u00e9todos. \u00c9 assim que voc\u00ea pode vincular qualquer visualiza\u00e7\u00e3o e ViewModel, desde que tenha as propriedades corretas. A associa\u00e7\u00e3o XAML tamb\u00e9m permite que voc\u00ea associe n\u00e3o apenas dados, mas tamb\u00e9m a\u00e7\u00f5es \u00e0 visualiza\u00e7\u00e3o. Definimos um objeto como uma propriedade do modelo e o vinculamos declarativamente \u00e0 propriedade correspondente na visualiza\u00e7\u00e3o. O resultado \u00e9 um objeto separado que cont\u00e9m dados e comportamento, independente da visualiza\u00e7\u00e3o. O ViewModel \u00e9 uma combina\u00e7\u00e3o de Model e Controller.<\/p>\n As principais vantagens do MVVM s\u00e3o o design f\u00e1cil da interface, o teste independente e o c\u00f3digo reduzido para a visualiza\u00e7\u00e3o.<\/p>\n Se usarmos os padr\u00f5es MV* para separar o c\u00f3digo da visualiza\u00e7\u00e3o, do modelo e do controlador, em sistemas altamente carregados, ser\u00e1 poss\u00edvel obter um benef\u00edcio adicional ao separar esses elementos em diferentes unidades computacionais.<\/p>\n Ao desenvolver o ITSM-system SimpleOne<\/a>, o padr\u00e3o Model-View-Controller \u00e9 tomado como base, o que \u00e9 significativamente otimizado. A fun\u00e7\u00e3o de visualiza\u00e7\u00e3o \u00e9 desempenhada por um aplicativo SPA de p\u00e1gina \u00fanica, que \u00e9 executado inteiramente no dispositivo do cliente e recebe apenas dados do modelo. E para a opera\u00e7\u00e3o do modelo, usamos a abordagem DDD (Domain-Driven Design<\/a>) – dividimos o padr\u00e3o em camadas – reposit\u00f3rios por meio dos quais os dados s\u00e3o acessados.<\/p>\n No MVC tradicional, o c\u00f3digo do modelo \u00e9 projetado para um banco de dados espec\u00edfico e sua sintaxe, por exemplo, PostgreSQL. Usando o sistema de reposit\u00f3rio, podemos trocar de camadas e conectar qualquer outro banco de dados sem alterar o c\u00f3digo do aplicativo.<\/p>\n As camadas nos permitem n\u00e3o apenas trabalhar com reposit\u00f3rios como conectores ao banco de dados, mas tamb\u00e9m dividir quaisquer classes em entidades separadas. Por exemplo, se em um modelo MVC comum a classe User cont\u00e9m v\u00e1rios milhares de linhas de c\u00f3digo e \u00e9 respons\u00e1vel por todas as opera\u00e7\u00f5es relacionadas ao usu\u00e1rio (pesquisa, exclus\u00e3o, envio de mensagens e outras), no SimpleOne n\u00f3s a dividimos em v\u00e1rias camadas separadas: a classe de descri\u00e7\u00e3o do usu\u00e1rio, o reposit\u00f3rio do usu\u00e1rio para trabalhar com o banco de dados, as classes de v\u00e1rios servi\u00e7os relacionados ao usu\u00e1rio e outras. Obtemos uma estrutura MVC, mas mais profundamente desenvolvida, permitindo a troca, uma execu\u00e7\u00e3o de consulta muito mais r\u00e1pida e mais f\u00e1cil de manter.<\/p>\nModelo e visualiza\u00e7\u00e3o<\/h2>\n
Model-View-Controller<\/h2>\n
\n
Model-View-Presenter<\/h2>\n
Model-View-View-ViewModel<\/h2>\n
Otimiza\u00e7\u00e3o e desempenho<\/h2>\n
\n
MVC no SimpleOne<\/h2>\n
Conclus\u00e3o<\/h2>\n