MVC e 3 tier

What is classpath? Membro desde: 19/01/2010 17:14:49 Mensagens: 5 Offline

em MVC+3 tier é correto afirmar que:

forms etc.. ->MVC - V | 3 tier - Tier 1
façade etc.. ->MVC - C | 3 tier - Tier 2
repositorios,entities etc.. ->MVC - M | 3 tier - Tier 2
persistencia em geral -> 3 tier - Tier 3

??

JavaBaby Membro desde: 21/01/2007 22:55:29 Mensagens: 83 Offline

Tiers=Servers.
Layer=Separação Lógica
MVC=Separações Lógicas (apresantação, dados)

No caso de 2-tiers:
O M no client tier e EIS.
O V no client tier.
O C no client tier.

No caso de 3-tiers:
O M no middle tier e EIS.
O V no client tier, middle tier.
O C no middle tier.

Ou seja, layer e tiers são coisas distintas.
MVC tem a ver com layer.
Em que tier fica esse layer?; Depende...

Tem zilhões de tópicos sobre MVC aqui no GUJ. Provavelmente 90% vão te apontar pra esse link:

http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

No mais, tiers são camadas separadas fisicamente. Layers são camadas Lógicas. MVC pode ser aplicado indiferentemente de layers ou tiers. Ou seja, pode-se aplicar MVC em uma aplicação com apenas uma layer.

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 824 Offline

Crown wrote:em MVC+3 tier é correto afirmar que:

forms etc.. ->MVC - V | 3 tier - Tier 1
façade etc.. ->MVC - C | 3 tier - Tier 2
repositorios,entities etc.. ->MVC - M | 3 tier - Tier 2
persistencia em geral -> 3 tier - Tier 3

??

Não existe uma teoria única que misture MVC, Camadas e Padrões.

MVC é uma técnica para separar lógica de apresentação de um modelo do modelo em si. Camadas são separações lógicas do sistema para controlar dependências e reduzir complexidade. Ou seja, ambos tem objetivos diferentes; e é possível tanto ter um sistema com MVC sem camadas, quanto ter um com camadas e sem MVC.

Outra, você não classifica tudo no MVC. Ninguém nunca diz: "Ah, a classe java.util.Calendar faz parte do Model!". Não! Você põe na divisão do MVC aquilo que faz parte do domínio da sua aplicação. Lógica de persistência ou qualquer outra coisa de infraestrutura está fora da sua classificação de MVC.

Patterns não tem razão para pertencer a alguma camada específica ou a algum componente do MVC. Se eu precisar de Facade na View, eu uso; se eu precisar de Facade no Model, eu também uso; se eu precisar de DAO para a view (talvez para salvar a disposição mais recente dos componentes visuais), eu uso. Não tem sentido dizer que só uso tal pattern na camada X no componente Y.

Estude tanto MVC, Camadas e Patterns como se fossem coisas separadas e como se fossem maneiras diferentes de enxergar a estrutura interna de um sistema. Unificar as coisas é infrutífera.

Notícias, artigos e o maior fórum brasileiro sobre Java