Aplicativo MVC.Como mult-tier architecture encaixa?

Question

Eu sou novo para o conceito de MVC e multi-camadas da arquitetura da web.Desenvolvimento de uma aplicação PHP e estou usando um dos frameworks MVC.A minha pergunta é a seguinte:

Pelo que eu entendo, MVC em si não é considerado uma arquitetura de várias camadas.Eu posso entender como o uso de MVC sozinho é um passo de tomar um não-estruturado abordagem, mas eu estava pensando em como uma simples arquitetura em 3 camadas encaixaria?Seria MVC residem na camada de apresentação?Quais são as vantagens de adicionar uma abordagem em níveis?Pelo que eu sei, com MVC sozinho não há explícita de objetos de dados responsável por recuperar dados do banco de dados e geralmente é recheado para o modelo.Da mesma forma, a lógica de negócios, que, em 3-camadas da arquitetura reside em um "negócio de camada" (ou o que você quiser chamá-lo), pode ser recheado para o controlador.

É o meu entendimento um pouco correto?Eu sei que fiz muitas perguntas, mas eu gostaria de ouvir você falar sobre como se incorporou uma arquitetura de várias camadas em sua estrutura MVC (PHP ou qualquer outra) como eu suponho que os dois não são mutuamente exclusivos.Obrigado!

Answer 1

M) M é o seu modelo.Este é, geralmente, vivem em sua camada de negócios ou a camada logo atrás da camada de apresentação.Muitas pessoas não gostam do que a camada de apresentação tem qualquer conhecimento da camada de negócios, embora, e então eles mais abstrato que por ter o que é chamado de um ViewModel.Frequentemente estas são DTO (data transfer objects) que livremente mapa para o seu modelo de Domínio.Para mim.net cara), existem ferramentas como o AutoMapper para fazer a conversão do Modelo de Domínio para o Modelo de modo de Exibição.

V) V é a sua visão.A vista é a sua camada de apresentação.Este é o real HTML ou PHP de código que o usuário diretamente toca e interage.A visão deve ser o mais leve possível (ou seja, sem lógica, se possível).Tente manter qualquer tipo de if/then tipo de cenários de fora da vista e ater-se apenas a visualização e a coleta de dados.Apresentar um ViewModel para sua web designers, de modo que eles não contaminar o seu DomainModel.

C) C é o seu controlador.Isso é muito parecido com um coordenador.Ele usa os dados do seu ponto de vista e certifica-se de que obtém o direito de back-end função/método para processamento de dados.Ele também coordena dados de back-end em seu caminho para a frente.

Onde multi-camada de conceitos de design vêm em está por trás da camada de Apresentação (onde é o lugar onde MVC é principalmente).Quando o controlador está tomando dados do modo de exibição e passando-o de volta para o back-end (se você seguir DDD ou Domain Driven Design) iria passar os dados para um aplicativo de serviço (uma classe que coordena o back-end questões).O serviço pode continuar a empurrar os dados em um Repositório de camada (que é uma classe que fala para o banco de dados, sistema de arquivos, web services, etc.- qualquer infra-estrutura material).O DDD é um grande tema, mas vai obter a sua cabeça em torno de n-tier abordagem e como ele funciona com o MVC.

Enquanto a investigar este tópico dê uma olhada no IoC (inversão de controle), DI (injeção de dependência), TDD (test driven development), e como muitos padrões possíveis (fachada, fábrica, etc.).

Answer 2

Em geral, a lógica de negócios não deve ser o Controlador - você acabar com enorme controladores se você seguiu este padrão.O Modelo, basicamente, todas as casas de sua não-apresentação camadas ...o acesso a dados, lógica de negócios, de negócios e de objetos de entidade.O controlador prepara o negócio de dados para o modo de exibição.