Como a arquitetura de três camadas do MVC (ASP.NET MVC) pode funcionar juntos?

Question

Estou escrevendo um documento de design e as pessoas da minha equipe estão dispostas a mudar do ASP.NET WebForm para o ASP.NET MVC. Isso é ótimo, mas tenho dificuldade em entender como o MVC funciona em uma arquitetura de 3 camadas (camada de dados, camada de negócios e camada de apresentação). Podemos dizer que o modelo, a visualização e o controlador fazem parte da camada de apresentação? O modelo é parte da camada de negócios?

Em resumo, como o MVC e a arquitetura de três camadas podem funcionar juntos? Obrigado pela ajuda!

Answer 1

Considero o ASP.NET MVC na camada de apresentação. As classes "modelo" que ele usa são realmente modelos de exibição, que descrevem as estruturas de dados necessárias para suas visualizações. Toda a sua lógica de negócios e acesso de dados devem permanecer separados dos seus modelos e controladores MVC.

Além disso, a "prática recomendada" geral para o MVC é manter o código do controlador o mais simples possível, o que geralmente significa introduzir alguns para o serviço de aplicativo em sua camada de negócios que lida com o levantamento pesado.

Answer 2

A camada de apresentação é a sua opinião.

A camada de dados é o seu modelo (recomendo olhar para o padrão do repositório).

A camada de negócios continua sendo o que é.

O controlador pode chamar a camada de negócios para funcionalidade quando o objeto é carregado, ou o modelo pode chamar a camada de negócios para funcionalidade quando um viewmodel específico é solicitado, mas, caso contrário, permanece o mesmo.

O controlador não deve ter uma lógica de negócios expansiva-coloque isso em sua própria DLL independente.

Answer 3

Isso é bastante subjetivo. Faça o que faz sentido para sua equipe.

O MVC pode ser bastante flexível e quase nenhuma estrutura MVC, em todos os idiomas, faz as coisas da mesma maneira. Mesmo no espaço .NET. Fubumvc, Spring.net e MS MVC fazem as coisas de maneiras ligeiramente diferentes.

Answer 4

Primeiro de tudo, você não precisa mudar para o MVC só porque ... se você tem algo que está funcionando, acho que não precisa.

Mas, para você questionar, o modelo no padrão MVC é qualquer tipo de classe que represente seu problema de negócios, o que pode ser qualquer tipo de cálculo, regras de negócios ou classes de acesso a dados. Na estrutura do MVC, há uma pasta como uma maneira de propor uma solução para você, para que você possa colocar suas classes de modelo lá, mas não precisa, você pode criar projetos diferentes para resolver seus problemas de negócios e esse é o seu modelo. Então, aqui, você pode definir qualquer outro padrão que você for Instante, você pode usar o padrão do repositório e implementar que o uso da estrutura de Nhibernate ou entidade.

As visualizações são apenas páginas da web para mostrar e receber informações de e para o usuário.

E o controlador é a entrada do seu aplicativo, as classes que receberão as solicitações, ligue para os modelos necessários e redirecionam para a visualização especificada.

Espero poder ajudar.

Answer 5

N-Tier com MVC funciona muito bem. Basta seguir o princípio sólido e vários outros e você poderá manter seu aplicativo vagamente acoplado e coeso.

Eu diria que ler os livros no MVC 3 e assistir a vídeos PluraSight.com são seus maiores recursos. Você não pode ir com "Faça o que funciona para sua equipe". Se, digamos, os associados denominados Johnny e Timmy querem colocar um monte de lógica em um controlador, apenas porque, no prazo de curto prazo, "funciona para sua equipe", que não o torna certo / bom / inteligente.

Eu encontrei tantos artigos ruins na internet que é assustador quantas pessoas estão sendo levadas por um caminho sombrio de miséria. Siga o caminho feliz. Use StackOverflow para opinião como arte, mas verifique com artigos MSDN, livros MVC e pluralsight.com

Answer 6

Eu sei que é apenas um link da Wikipedia, mas há algumas informações aqui Em relação à arquitetura N-Tier vs. MVC.

Answer 7

Uma "camada" é uma unidade de implantação, enquanto uma "camada" no MVC é uma separação lógica de responsabilidade dentro do código.