|
Usuários |
|
66 Usuários Online
|
|
[Artigos]
[Intermediário] - MOVE: um padrão de arquitetura alternativo |
Publicado por rboaro : Quinta, Novembro 07, 2013 - 01:40 GMT-3 (679 leituras)
 comentar  Enviar para um amigo  Versão para impressão
|
Padrões de arquitetura de software, como já mencionei em outro artigos, é muito importante 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.
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, não são um mar de rosas. 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”.
Padrão de Arquitetura MOVEPartindo para uma abordagem mais técnica, imagine que você esteja trabalhando com o MVP. A View é somente o visual da aplicação e não deve conter nenhum código-fonte. Sendo assim, eventos como o clique de um botão e 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 regras de tela. 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 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.
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 e 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 ir mais a fundo.
A estrutura do MOVE consiste na seguinte organização:
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, estendo 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 de uma aplicação 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 esse CPF aqui, 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? rsrs…
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 a gente consegue resolver utilizando Interfaces, não é?
Mais informações sobre MOVEMais informações sobre o MOVE podem ser encontrados neste link. No entanto, em 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.
Você já testou o MOVE?
Ainda não. 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 SubRotina com mais detalhes.
Abraço, pessoal!
Até a próxima semana!
Link Original do Artigo: http://www.subrotina.com.br/move-um-padrao-de-arquitetura-alternativo/
|
|
 Comentários | |
| | Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos. |
|
|
Edição 112 |
|
|
50 Programas Fontes |
|
|
Produtos |
|
|
