Tomara que tu continues assim :)

Abraços,

Marcelo

“Na maioria dos casos pode-se definir o Controller dentro da Camada de Aplicação. Esta Camada ficaria responsável então por mostrar o estado do Model ao usuário e receber as requisições deste.

Algumas vezes, entretanto, é necessário que o Controller fique isolado desta. Este é o caso, por exemplo, quando possuímos mais de uma interface, como Swing e HTML. Neste caso, pode-se utilizar uma Camada que quase sempre está implícita, a Camada de Aplicação.”

O primeiro não deveria se referir à camada de Apresentação?

(1) Eu concordo, foi falta de atenção ao criar o diagrama, mas na verdade não poderiamos afirmar isso só de olhar a figura. Depende dos requisitos, do sistema… realmente ficaria mais claro, creio, mas a presença dos objetos de negócio é meramente ilustrativa.

(2) Em sistemas seguindo o MVC original isto é verdade, mesmo Swing. Basta ver a presença dos XyzModel na biblioteca do próprio Swing que ao serem atualizados refletem as mudanças nos componentes. O ponto é que nem sempre se usa o MVC original.

Sim, MVC é apenas uma dos diversos modelos de interação entre componentes. Ele foi abordado no artigo por ser o mais (mal-)utilizado no desenvolvimento atual, pelo menos para aplicações Java, e por gerar esta eterna dúvida com a técnica de Camadas.

[]s e obrigado pelo feedback

O tema do artigo é bem interessante e promove uma discussão saudável sobre esses conceitos.
Eu tenho alguns pontos para discutir:

(1) O modelo apresentado na primeira figura (diagrama de classes) aparentemente apresenta um erro de modelagem: o grupo é quem agrega os usuários, e não ao contrário. Correto?

(2) Outro ponto, você disse no artigo que a visão “escuta” as mudanças no modelo. Bom, isso talvez possa ser verdade em alguns sistemas (não sei), mas em software desktop isso definitivamente não ocorre. Quem modifica a visão é o controlador, que possui uma referência para ela. Tanto é que esse é um problema que o padrão Presentation Model ajuda a solucionar (meu próximo artigo na Java Magazine, além dos artigos no meu site) :-)

É interessante lembrar que o MVC é apenas uma das formas de interação entre camadas, possivelmente usado por ser um dos mais famosos. Outro padrão, por exemplo, é o uso de um barramento (bus) por onde a informação trafega (claro que isso depende do objetivo da aplicação). Existe um monte de padrões arquitetônicos (ou arquiteturais) no livro do Buschman (1995) que vale a pena sempre lembrar.

Bom, eu só quis complementar suas idéias ;-)
Será que eu falei alguma coisa fora de foco?

Grande abraço,
Hugo.

[]s

O artigo ficou legal, mostra de maneira bastante clara a diferença entre os dois conceitos,

*encontrei um pequenino erro de digitação

*Penúltimo parágrafo da sessão “MVC: Interação Entre Componentes”

“Na maioria dos casos pode-se definir o Controller dentro da Camada de Aplicação. Esta Camada ficaria responsável então por msotrar o estado do Model ao usuário e receber as requisições deste.”