Práticas recomendadas para arquitetura MVC [fechado]

Minha pergunta é mais sobre como arquitetar um aplicativo MVC. Por exemplo, somos encorajados a usar DI com o padrão Repository para desacoplar o acesso a dados do controlador, no entanto, muito pouco é dito sobre COMO fazer isso especificamente para o MVC. Onde colocaríamos as classes Repository, por exemplo? Eles não parecem ser especificamente relacionados ao modelo, pois o modelo também deve ser relativamente dissociado das tecnologias de acesso a dados reais.

Uma segunda pergunta envolve como estruturar as camadas ou camadas. A maioria dos aplicativos de exemplo (jantar Nerd, Music Store etc.) parece usar uma abordagem de camada única, de duas camadas (sem contar os testes) que normalmente possui controladores que chamam diretamente o código L2S ou EF.

Se eu quiser criar um aplicativo multicamada / camada, quais são algumas das práticas recomendadas no MVC?

asp.net-mvc architecture

— Erik Funkenbusch
fonte

Respostas:

O DI é realizado no ASP MVC usando uma Controller Factory. Esta fábrica é usada para resolver as dependências do seu controlador.

O MvcContrib possui algumas implementações do Controller Facotry que você pode usar imediatamente. Eu uso a implementação do Castle Windsor e funciona bem. Também sugeriria verificar sua classe TestHelper. Possui algumas funcionalidades muito interessantes para zombar do Controlador HTTPContext, Sessões, etc. MVCContrib

Pessoalmente, gosto de dar aos meus modelos uma instância de repositório para trabalhar. O modelo expõe uma API ao repositório (CRUD). A dependência do controlador em um modelo específico é injetada na criação (construtor), que é injetada através da Controller Factory. Este é o meu ponto de entrada para o gráfico de objeto que meu contêiner de IoC gerencia.

Onde colocaríamos as classes Repository, por exemplo?

Eles pertencem ao modelo; eles são o modelo no aplicativo.

Como faço para estruturar as camadas? Se eu quiser criar um aplicativo multicamada / camada, quais são algumas das práticas recomendadas no MVC?

Camadas Representam separações físicas de código. Camadas representam separações lógicas. As camadas (como são atualmente) funcionam bem para o MVC. Dependendo da quantidade de lógica de negócios, ela pode ser colocada em seu Controlador ou em um conjunto separado e pode ser usada pelo controlador durante o ciclo de solicitação.

— George Stocker
fonte

Então, você está sugerindo que eles entrem no projeto de interface do usuário de um aplicativo de várias camadas?

— Erik Funkenbusch

@Mystere Man Se não for gigantesco, eles devem entrar no projeto que hospeda seu aplicativo MVC. Especificamente, a lógica de negócios entraria no controlador e cada ação teria sua própria lógica. O MVC não é apenas um padrão apenas da interface do usuário; é por isso que discordo da sua afirmação de que é um 'projeto de interface do usuário'. Não é. É um projeto MVC que, como uma Viewseção (existe a sua interface do usuário).

— George Stocker

Ok, talvez eu tenha falado mal. No entanto, você não concorda que a camada de visualização não deva manipular o banco de dados? E se você colocar as classes Repository no modelo, a exibição poderá fazê-lo.

— Erik Funkenbusch

em um aplicativo MVC pequeno, a interface do usuário "Camada" é simplesmente a pasta que contém as visualizações. Em uma aplicação maior, poderia ser seu próprio projeto. Se for seu próprio projeto, ele se coordenará com o controlador, e o controlador poderá se conectar ao BusinessLayer conforme necessário. Ninguém fora do controlador precisaria saber que a camada de negócios existia. Eu acho que você está automaticamente pensando que esses projetos estão separados, mas eles não precisam.

— George Stocker