duvida sobre MVC e Facade

[wardog1]

Srs.,

DAO e DAOFactory pertencem ao model
php para montar o html, pertence à view
Controller é Controller

Tenho uma dúvida sobre a classificação do Facade dentro do MVC

Facades servem para chamar consumir o Model na minha opinião.

Se Facade pode ser reutilizado por vários Controllers, então o Facade pertence ao Model.

Qual a opinião dos colegas?

Facade pertence ao Controller ou ao Model?

Antes que alguém diga que depende se o Facade está sendo usado pelo Model ou pelo Controller, já digo que estou ciente disso.

Na minha opinião, pertence ao Model.

--
Att,
Roberto Messa
RemoteControl
Framework para Celular WAP
http://mobile.sybrain.com
21 95842096

[Bruno Reis]

O Facade provê interface simplificada para o conjunto de APIs de um
subsistema, esteja ele em que camada for. O Facade por si só não tem
como ser classificado "dentro do MVC" porquê MVC não é uma
categorização de padrões e sim separação de camadas. Existem alguns
padrões, principalmente os J2EE, eu diria, que se inserem mais nessas
camadas. Mas o Facade por si só é puro. É igual o Composite, por si só
não diz onde fica. Mas aí a Sun inventou o CompositeView e o
CompositeEntity.

Poderiamos também inventar o ServiceFacade (se é que já não existe), o
BusinessFacade e o ControlerFacade. Apesar de que algumas
implementações de FrontController, ao meu ver, já agem como um Facade.

2009/7/10 wardog1 <war...@gmail.com>

[felipebastos]

pelo q vi .. facade nao tem muito haver com mvc .. mas pode ser usado
em alguma classe

[felipebastos]

o Facade .. não recordo direto como é ..

mas o Model geralmente funciona como o session facade (faz a função,
ele é a implementação do pattern) .. ele importa Dao e Value Object e
executa ações sobre o banco ..

isso pq ele é a interface de entrada para toda manipulação de banco ..
não importando quais drivers serão usados para isto

certo ??

no ebook http://www.scribd.com/doc/7344954/Construindo-uma-Arquitetura-de-Desenvolvimento-em-PHP-5
mostra uma classe session facade que faz exatamente a função do
Model .. vc notara a semelhanca bem rapidamente ..
.
eu , particularmente, gosto de descartar o model .. e colocar o Dao
para fazer o papel dele .. isto pq tenho uma classe DB (poderia ser
PDO ou AdoDB) para gerenciar os drivers do banco .. então achei
redundante [enchimento de choriça] manter o Model ..

[Bruno Reis]

O SessionFacade é um padrão da Sun (Core J2EE Patterns, pag. 341), que
segundo eles é usado para prover uma interface com granulariedade mais
alta (mesma coisa que o Facade) e também para para acesso por clientes
remotos à camada de negócio. Poderia ser algo usado para expor um
web-service ou para ser acessado direto por uma RIA. Pode conter ou
não informações de estado, mas não deve conter informações de negócio.

Eu gosto de usar algo semelhante, expondo para a camada de controle
apenas métodos que ela necessite usar e tirando toda a lógica das
actions. Na action eu recebo informações e jogo para "baixo", depois
só recebo de volta uma resposta ou uma exceção, sem ifs elses e outras
estruturas desse tipo, a não ser que possam auxiliar a preparar dados
para a view. Fica bem "limpim" desse jeito.

2009/7/12 felipebastos <feli...@gmail.com>:

[Fernando Mantoan]

bom, o Facade não pertence a alguma parte específica do MVC e acredito
que ele seja um complemento a ele.
Segundo o livro de design patterns da Gang of Four, o conceito do
Facade é:
"O padrão de projeto Facade fornece uma interface única para um
conjunto de interfaces de um subsistema. Uma Facade define uma
interface de mais alto nível que torne o subsistema mais fácil de ser
utilizado."
A forma como eu utilizo o Facade é para complementar o Controller,
escondendo dele as partes de chamar models e etc, fazendo com que ele
controle o fluxo entre a view e a Facade, deixando o cargo de acessar
o Model à camada Facade. Para se ter um exemplo, ao se recuperar dados
de models utilizando o Doctrine, o Controller deveria conter o
seguinte código:
$tarefa_table = Doctrine::getTable('Tarefas');
$tarefas = $tarefa_table->allData();

No meu caso, eu utilizo o Facade para esconder esse tipo de coisa e
também qualquer outra lógica que seja necessária ao fazer acessos ou
passar dados ao Model, fazendo com que o Controller seja única e
exclusivamente responsável por controle de fluxo (essa na verdade
deveria ser sua função). Assim o código da controller fica mais limpo,
organizado e faz jus ao seu nome CONTROLAR o fluxo. Mas eu também
posso estar enganado, me corrijam qualquer coisa galera! :)

[Bruno Reis]

Acho que é isso mesmo Fernando, eu fiquei na dúvida quanto ao Facade
implementar ou não lógica dentro dos seus métodos, mas o exemplo do
GoF (class Compiler, pg. 191) mostra este tipo de implementação.
Usamos desta mesma mesma maneira aqui e estamos satisfeitos com os
resultados e qualidade do código.

O "livro do GoF" ate sugere que, se possível, as classes do negócio
sejam acessíveis apenas pelas classes do Facade (não podendo ser
acessadas diretamente pela action), mas não vejo maneira simples de
implementar isso em php. Talvez com algo tipo package em Java fosse
possível, mas não conheço bem para dizer.

2009/7/13 Fernando Mantoan <ferna...@gmail.com>: