Padrões de arquitetura de software, como já mencionei em outro artigos, são muito importantes no desenvolvimento de um software orientado a objetos. Provavelmente você já deve conhecer os padrões MVC, MVP e MVVM, certo? O que você talvez não saiba é a existência de mais um padrão de arquitetura, mesmo que pouco comentado, conhecido como MOVE. Confira o artigo para conhecer a estrutura que este padrão sugere em uma aplicação.
Antes de começar, gostaria de fazer um agradecimento especial ao Francisco Luiz, um dos leitores que sempre acompanha o blog e que sugeriu a elaboração deste artigo sobre o MOVE. Na verdade, a sugestão do Francisco Luiz foi uma surpresa. Eu não conhecia o MOVE (talvez pela escassez de material na web), então esse padrão foi uma novidade pra mim.
Introdução
Pois bem, se você já trabalhou com um algum padrão de arquitetura, sabe que eles são bastante funcionais, porém, por outro lado, empregá-los em uma solução não é tão simples. A implementação de um padrão de arquitetura exige alto conhecimento em abstração, inversão de dependência e conceitos de coesão e acoplamento. Talvez um pequeno equívoco na modelagem da aplicação pode resultar na duplicação de código ou responsabilidades desnecessárias em algumas classes. No MVC, por exemplo, em muitas situações é necessário utilizar Design Patterns para remover dependências entre classes e evitar o que alguns profissionais chamam de “código espaguete”.
Partindo para uma abordagem mais técnica, imagine que você esteja trabalhando com o MVP. A View representa somente o visual da aplicação e não deve conter nenhum código-fonte referente à regra de negócio. Sendo assim, eventos que disparam ações como o clique de um botão ou a entrada de dados em um campo devem ser recebidos pelo Presenter, que por sua vez, os envia para a Model quando necessário. Neste caso, eu afirmaria que o Presenter está representando duas funções: a de intermediação entre View e Model e a de Listener (ouvinte) da View para administrar eventos de regras de negócio. Se isso não for bem tratado, o Presenter se transformará em um emaranhado de código em pouco tempo.
MOVE
Por que não abstrair um pouco mais e rever essa comunicação entre os componentes? Essa é a proposta do MOVE.
Neste padrão, encontramos quatro artefatos: Models, Operations, Views e Events. Basicamente, pense na camada Operations como um Presenter ou um Controller. Agora, considere que a engrenagem gira conforme os eventos (Events) são disparados na aplicação.
Ao clicar em um botão, por exemplo, a View emite um evento para a Operation, que então emite um evento para a Model e, por fim, a Model emite um evento de notificação para a View.
Sei que, em primeira instância, o fato da camada Model “conversar” com a View é um pouco diferente do que estamos habituados. Em outros padrões, a camada Model não conhece a View e precisa de um “intermediário” para enviar as notificações que, neste caso, é o Presenter ou o Controller. No MOVE, há uma comunicação entre Model e View para atualização do estado da tela.
Prosseguindo, a estrutura do MOVE consiste na seguinte organização:
Fonte: [IRWIN, 2012]
http://cirw.in//blog/time-to-move-on.html
Funções das camadas
A camada Model encapsula a regra de negócio de uma aplicação. Além dos tradicionais getters e setters, a Model possui funções de validação (como a verificação de um CPF, cálculo de valores…), mas não é responsável por persistir dados no banco.
A camada Operation é a mais importante do MOVE, responsável por executar as operações disparadas pela interação com o usuário e gerenciar a persistência no banco de dados.
Opa, aqui deixo um adendo. Quando eu normalmente trabalho com MVC, procuro estender a camada Model em duas abstrações: modelagem (Model) e persistência (DAO). Já discuti essa prática com muitos desenvolvedores que também fazem essa separação com o intuito de manter as classes de modelagem independente da conexão com o banco de dados. No MOVE acontece essa separação, mas de forma natural: a camada Model envolve a regra de negócio enquanto a Operation faz as operações (como de persistência), logicamente, rsrs.
A camada View ganha a função de ouvinte da Model, ou seja, além de apresentar os dados ao usuário, essa camada aguarda uma notificação da Model para alterar o estado atual. Por exemplo, se o CPF do cliente é inválido, a Model envia um evento para a View e essa, por sua vez, exibe uma mensagem na tela informando a inconsistência. Observe que nessa situação não há comunicação com a Operation, pois ela já fez a sua parte: obteve o número de CPF digitado pelo usuário e o enviou para a Model para validação. É o mesmo que dizer: “Model, o usuário digitou este CPF, mas não sei se é válido. Se for inválido, por favor, se entenda com a View, eu não tenho nada a ver com isso”. Camada arrogante, não? 🙂
Por fim, os Events são mensagens emitidas pelas camadas para executar uma determinada tarefa. O objetivo em se ter Events em uma aplicação permite que as mensagens sejam disparadas entre abstrações, ou seja, o emissor não precisa necessariamente conhecer o receptor, desde que ele saiba que a mensagem é “compreensível”. Caso contrário, o receptor receberá a mensagem e não saberá o que fazer com ela. Bom, mas isso nós conseguimos resolver utilizando Interfaces, não é?
Conclusão
Mais informações sobre o MOVE podem ser encontradas neste link. No entanto, na minha opinião, o autor foi um pouco radical em dizer que o MVC “está morto” e que o MOVE é o futuro dos padrões. Embora eu concorde com o autor sobre a atualização dos padrões de arquitetura para trabalhar com novas ferramentas, conheço casos em que o MVC foi empregado com sucesso com tecnologias atuais e acredito que ele ainda será bastante utilizado. Mesmo assim, o MOVE é uma alternativa plausível para estruturar uma aplicação de uma forma diferente e funcional.
Ainda não tive a oportunidade de testar o MOVE. Portanto, não posso garantir o funcionamento deste padrão conforme a teoria sugere. Vale ressaltar que alguns autores já tentaram incorporar essa ideia do MOVE dentro do MVC com os conceitos de Objectify e Interactions, o que nos leva a acreditar que o MOVE pode ser aplicado com êxito em um projeto.
Leitores, este artigo trouxe apenas os conceitos do MOVE sem exemplos práticos. Quando surgir uma oportunidade para utilizá-lo, farei questão de compartilhar aqui no blog com mais detalhes.
Abraço, pessoal!
Até a próxima semana!