Técnico

Refatorando o ModelLocator do Cairngorm – Parte II

Primeiramente, desculpas pela demora em liberar a segunda parte desse post. ūüôā

Segundo, essa √© apenas uma tentativa de instigar a comunidade Flex a refletir e debater mais sobre as solu√ß√Ķes que adotam como boas pr√°ticas de programa√ß√£o no seu dia a dia.

Feitas as considera√ß√Ķes iniciais, podemos prosseguir.

Muitos desenvolvedores j√° est√£o cansados de ouvir a respeito dos padr√Ķes DI (Inje√ß√£o de Depend√™ncia) e IoC (Invers√£o de Controle). Desenvolvedores Flex, em especial, conhecem os benef√≠cios desses padr√Ķes atrav√©s da implementa√ß√£o do padr√£o Service Locator. O principal benef√≠cio tanto da DI quanto do Service Locator, √© que ambos promovem o desacoplamento entre as partes, diferenciando-se somente na forma como s√£o implementados.

Usando o padr√£o Service Locator, o locator esconde as depend√™ncias de outras implementa√ß√Ķes, mas voc√™ encontra certa dificuldade para encontr√°-lo em seu c√≥digo. J√° a DI facilita a visualiza√ß√£o das depend√™ncias do componente, uma vez que voc√™ pode simplesmente analisar o mecanismo de inje√ß√£o, como o construtor, para entender seu funcionamento. √Č evidente que ambas s√£o favor√°veis ao desenvolvimento, e sua escolha deve estar sempre baseada no seu contexto: Se sua aplica√ß√£o possui v√°rias classes que usam um servi√ßo, o uso do Service Locator pode ser mais favor√°vel, uma vez que a depend√™ncia das classes com o locator pode n√£o ser um grande problema.

Deixando as discuss√Ķes sobre refatorar o Service Locator para outro post (e talvez at√© um poss√≠vel refactoring no FrontController … rs), vamos agora definir a arquitetura da nossa aplica√ß√£o, destacar pontos de destaque, comparando e destacando seus benef√≠cios. Lembrando que o objetivo da aplica√ß√£o √© demonstrar como refatorar o ModelLocator do Cairngorm, de forma que ele se torne, finalmente, um ponto de acesso aos nossos modelos e n√£o nosso modelo de fato.

Acho oportuno citar uma frase que li numa apresenta√ß√£o do Bore Wessel, na √©poca consultor s√™nior do time de RIA da Adobe: “O Cairngorm oferece padr√Ķes sobre como voc√™ pode implementar uma dada funcionalidade, mas voc√™ n√£o precisa segui-los, nem mesmo o programador precisa seguir as boas pr√°ticas de programa√ß√£o da orienta√ß√£o a objetos”. Na mesma apresenta√ß√£o, ele segue dizendo que a prefer√™ncia dos consultores da Adobe √© de fato pelo uso do padr√£o Presentaion Model, quando definindo uma arquitetura para as views.

Vamos ver abaixo como nosso projeto foi organizado:

Vamos destacar dois pontos chaves, que precisam de sua atenção:

O Domain model da aplicação (AgendaModel.as), o qual encontra-se sob o pacote br.com..model.domain.
Essa classe √© respos√°vel por estruturar os dados da aplica√ß√£o e tamb√©m definir seus comportamentos. Nesse exemplo, vamos trabalhar com um √ļnico Domain Model, por√©m aplica√ß√Ķes de grande escala podem ter a necessidade de dividir a responsabilidade em mais classes Domain Models. Aplica√ß√Ķes modularizadas, por exemplo, porem ter um Domain Model para cada um dos seus m√≥dulos.

O Domain Model da aplicação é instanciado pelo nosso ModelLocator, conforme abaixo:

public static function getInstance():ModelLocator
{
if(instance == null)
{
instance = new ModelLocator();

// Os modelos s√£o instanciados quando
// nosso ModelLocator é instanciado
instance.agendaModel = new AgendaModel();
}

return instance ;
}

Os Presentation Models que est√£o sob o pacote br.com..model.presentation.
As classes Presentation Model possuem uma super classe (AbstractPM.as) que define seus comportamentos comuns. Aqui existe um importante detalhe de implementação: A super classe herda de EventDispatcher, pois nossas views não disparam mais events ou Cairngorm events, passando essa responsabilidade aos Presentations Models, desacoplando as views do Cairngorm. Dessa forma, as views da aplicação não possuem mais referências à propriedades do ModelLocator, e a dependência agora passa a ser com seu respectivo Presentaion Model.

Os Presentation Models das views internas são inicializados pelo Presentation Model principal da aplicação e possuem uma referência ao Domain Model da aplicação:

// Domain Model da aplicação
public var agendaModel:AgendaModel;
// Presentation Model da View ContatosView
public var contatosModel:ContatosModel;
public function AgendaPresentationModel(appModel:AgendaModel)
{
agendaModel = appModel;

// Presentation Model de uma view interna
// Repare que estamos injetando o Domain Model
contatosModel = new ContatosModel(agendaModel);
}

Outro ponto importante que merece destaque é o fato dos Presentation Models atualizarem nosso modelo diretamente, tirando essa responsabilidade dos commands.

public function result(data:Object):void
{
// Método setter no Presentation Model
contatosModel.contactsCollection = new ArrayCollection(data.result as Array);
}

O modelo agora é atualizado através da chamada de um método do Presentation Model, e não através de uma propriedade no ModelLocator.

Para os interessados em entender melhor o padrão Presentation Model, recomendo a leitura do blog do Paul Williams, onde há uma série de artigos interessantes a esse respeito e que foram importantes fontes de referência na construção desse post.

Veja abaixo um diagrama que exemplifica como as classes de Presentation Model e Domain Model relacionam-se com as views da aplicação nessa nova arquitetura:

No pr√≥ximo post, o c√≥digo completo de uma aplica√ß√£o utilizando a arquitetura e os padr√Ķes citados acima, refatorando totalmente o ModelLocator do Cairngorm.

Prometo ser mais r√°pido. ūüôā

Até a próxima pessoal!

Autor(a)

Pablo Souza

Coment√°rios (13)

  1. DClick Blog
    14 de janeiro de 2009

    […] aqui a segunda parte desse […]

  2. Anderson
    3 de fevereiro de 2009

    Previsão para a próxima parte do artigo?

    []’s

  3. Pablo Souza
    3 de fevereiro de 2009

    Ol√° Anderson,

    Estou preparando nessa semana algo relacionado ao iPhone,
    mas na semana que vem libero a próxima parte sim.

    Fica à vontade se quiser discutir algo à respeito.

    Um Abraço!

  4. Anderson
    3 de fevereiro de 2009

    Ok! Blz…

    Vamos l√°! rs

    Antes eu tinha a view da minha aplicação (APPView.mxml) que instanciava um componente (CView) e também continha uma referência do model (CModel).

    [Bindable]
    private var cm:CModel = new CModel();

    Pelo o que eu pude entender, o que faço agora é instanciar meus Presentation Models dentro do Presentation Model da view principal (mantive ele bindable), correto?

    Ficaria assim:

    Entendi direito? rs

  5. Anderson
    3 de fevereiro de 2009

    Eita… engoliram os trechos que continham tags! oO

  6. Anderson
    3 de fevereiro de 2009

    Ok! Blz…

    Vamos l√°! rs

    Antes eu tinha a view da minha aplicação (APPView.mxml) que instanciava um componente (CView) e também continha uma referência do model (CModel).

    [script]
    [Bindable]
    private var cm:CModel = new CModel();

    [mxml]
    [view:CView cm=”{cm}”/]

    Pelo o que eu pude entender, o que faço agora é instanciar meus Presentation Models dentro do Presentation Model da view principal (mantive ele bindable), correto?

    Ficaria assim:
    [view:CView cm=”{ModelLocator.getInstance().presentationModel.loginForm}”/]

    Entendi direito? rs

  7. Pablo Souza
    13 de fevereiro de 2009

    Ol√° Anderson. Exatamente!

    Esse (a view principal da aplica√ß√£o) deveria ser o √ļnico lugar onde voc√™ recuperaria a inst√Ęncia do ModelLocator, diminuindo assim sua depend√™ncia, e √† partir da√≠ voc√™ injeta os presentation model (modelo) das views que est√£o abaixo da view principal.

    Estou finalizando a √ļltima parte, espero postar ainda hoje ou no m√°ximo no fim de semana.

    Um abraço!

  8. DClick Blog
    13 de fevereiro de 2009

    […] visto no post anterior, vamos hoje liberar o c√≥digo-fonte completo da refatora√ß√£o para que voc√™s possam entender melhor […]

  9. Refatorando o ModelLocator do Cairngorm – Parte III « Rectius – RIA weblog
    16 de outubro de 2009

    […] visto no post anterior, vamos hoje liberar o c√≥digo-fonte completo da refatora√ß√£o para que voc√™s possam entender […]

  10. Elton Bicalho do Carmo
    24 de fevereiro de 2010

    Estou refatorando o meu ModelLocator, só estava esperando alguns embasamentos teóricos para convencer minha turma.

    Eu sempre disse que o nosso ModelLocator demorava mais para abrir do que nossa aplica√ß√£o. Nosso ModelLocator parece um maracan√£ lotado de VOs e outras “gambis” do view.

    Abraço meu jovem, espero que você publique mais dicas.

  11. Octacilio Nazare
    16 de maio de 2011

    Muito boa a explicação e comentários sobre a representação do Modelo Cairngorm. Estou começando a estudar essas práticas e pretendo me aprofundar no Flex. Vc está de parabens pela explanação.

  12. Refatorando o ModelLocator do Cairngorm – Parte III | redspark
    26 de janeiro de 2016

    […] visto no post anterior, vamos hoje liberar o c√≥digo-fonte completo da refatora√ß√£o para que voc√™s possam entender […]

Deixe um coment√°rio

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *