Profissionais TI - Pra quem respira informação

Como já sabemos, padrões de arquitetura de software são muito importantes no desenvolvimento de um software orientado a objetos. Provavelmente você já deve conhecer os padrões MVC, MVP e MVVM, não é? O que você talvez não saiba é a existência de 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.

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. Em algumas 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.

Por que não abstrair um pouco mais e rever essa comunicação entre as camadas?

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.

A camada Model conversa com a View?

Exato. Sei que isso, em primeira instância, é um pouco diferente do que estamos acostumados. 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.

Conte-me mais sobre o MOVE

Certo, hora de entrar nos detalhes. A estrutura do MOVE consiste na seguinte organização:

Fonte: [IRWIN, 2012]
http://cirw.in//blog/time-to-move-on.html

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 ou inserção de registros filhos), 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.

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 – Data Access Object). 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, incluindo a persistência.

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.

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. Logo, utilizar Interfaces no MOVE é muito importante.

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 utilizar 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 uma solução.

Abraço, pessoal!

Publicado originalmente no blog SubRotina