Arquitetura MVC - Quantos controladores eu preciso?

Estou codificando há um tempo, mas principalmente scripts e aplicativos simples. Eu mudei para uma nova função, onde se trata de desenvolver aplicativos da Web e usar uma arquitetura MVC adequada, por isso estou tentando desesperadamente aprender tudo isso muito rapidamente.

Espero que essa pergunta não seja muito parecida com " Boas práticas para arquitetura MVC ", mas, enquanto estou passando por alguns tutoriais diferentes, notei que alguns têm vários controladores para coisas diferentes.

De quantos controladores um único aplicativo Web precisa?

Sei que seria difícil responder sem um exemplo, portanto fornecerei um:

Inscrição:

1. Usuário faz login.
2. O usuário pode fazer uma de três coisas:
   a) Carregar um arquivo (armazenado em um banco de dados mongodb com metadados).
   b) Procure um arquivo.
   c) Saia.

Minha pergunta é geral, mas dei o exemplo para ajudar qualquer um que tente responder.

Para o seu exemplo, eu criaria dois controladores:

• Controlador de Sessões para Login e Logout (crie e destrua a sessão para o layout REST)
• Controlador de arquivos para tudo nos arquivos (index = search e create = upload)

Em geral, uma abordagem RESTful, na qual você pensa em tudo como um recurso que pode ser exibido, criado, editado e destruído, fornece uma boa idéia de como estruturar as coisas. Como você pode ver nos meus exemplos, eu não fico muito perto de cada verbo no REST.

Você provavelmente precisará de mais controladores para obter mais funcionalidades. Por exemplo, um Controlador de usuários em que os usuários podem criar novas contas. Além disso, você precisaria de uma interface de administração na qual possa editar os recursos com privilégios mais altos. Nesse caso, é bastante comum ter quase todos os controladores duplicados.

Uma estimativa muito aproximada para obter uma idéia inicial pode ser um controlador para cada tabela em seu banco de dados que os usuários possam acessar. Mas esta é realmente apenas uma medida muito grosseira.

Realmente depende do aplicativo da web. No seu exemplo, um é provavelmente suficiente. Se você implementasse um aplicativo de comércio eletrônico completo com frete, impostos, gerenciamento de inventário, preços em camadas etc., talvez queira ter mais alguns.

Se o seu controlador sofre de um ou mais odores de código (especialmente Classe Grande ou Objeto Deus ), então você sabe que provavelmente já passou do ponto em que apenas um fará.

Realmente depende das necessidades da sua aplicação e da arquitetura dos módulos de negócios.

Como regra geral , o número de controladores necessários depende de vários módulos e submódulos no aplicativo Web.

Como um complemento, seria útil organizar os controladores em Áreas . O conceito de Áreas é incorporado à estrutura do ASP.NET MVC e simplifica a organização dos controladores que atendem a um módulo.

Há várias discussões relacionadas:

• Arquitetura MVC
• Design de ações do controlador ASP.NET MVC
• Organização dos diretórios mvc Controller And View
• Como é a organização da classe MVC para várias visualizações e controladores?

Eu gosto da maneira da Apple de fazer isso.

Toda visualização é controlada por apenas um controlador de visualização. ~ Ver Guia de programação do controlador para iOS

A ideia é que você possa trocar facilmente as Views. Na IMO, ao ter apenas 1 Controllerpor Viewisso, é mais fácil fazer isso. Mas tenho certeza de que você pode ter um controlador com várias visualizações e ainda projetá-lo para poder alternar as visualizações sem alterar a lógica do programa.

Um exemplo que eu gosto é pensar em um termostato. Um termostato é um excelente visual para visualizar o padrão MVC.

Em um termostato analógico mais antigo, você pode imaginar coisas como estas:

Ver - O leitor de temperatura, que exibe a temperatura atual.

Controlador - o mostrador, onde você altera a temperatura

Modelo - As partes internas invocadas pelo controlador que causam alterações na temperatura.

Você deve sempre respeitar os projetos que permitem o acoplamento flexível e limitar os modelos e seus controladores associados a uma única tarefa , além de usar quantos módulos / controladores forem necessários . Dependendo do tamanho do seu aplicativo, você pode ter muito menos visualizações do que modelos e controladores. Isso é esperado em qualquer aplicativo de tamanho grande. A boa programação orientada a objetos é caracterizada por acoplamento frouxo, encapsulamento, herança e polimorfismo. Nem todos os idiomas suportam polimorfismo no mesmo grau (função, método, sobrecarga / substituição do operador).

Se você deseja entender melhor o uso correto da arquitetura MVC, consulte o GoF "Design Patterns: Elements of Reusable ... Software", que usa C ++ e SmallTalk, por exemplo, código. Este livro não é o alfa e o ômega, mas certamente é um começo!

Boa sorte!

Suponho que seu exemplo evolua para um sistema complexo.

Inscrição:

Usuário efetua login:

• LoginController

Sua única responsabilidade é manipular logins, redirecionar ou notificar o usuário sobre o resultado.

Enviar um arquivo

• UploadController

Presumo aqui que você deseja fazer upload de qualquer tipo de arquivo. Se, posteriormente, você decidir fazer upload de MP3s e PDFs, eu teria um UploadController básico, um MP3UploadController e um PDFUploadController.

Procure um arquivo.

• SearchFileController

Isso seria suficiente para um requisito básico. Você pode ter vários controladores de pesquisa posteriormente, dependendo da complexidade da lógica de pesquisa. A última coisa que você deseja é um único SearchController com 20 métodos de ação executando pesquisas diferentes.

Sair.

-LogoutController .

Pode-se considerar que isso é um exagero, mas acho que não. Eu acho que é limpo e bem separado.

Se eu visse essa estrutura do projeto, saberia instantaneamente o que ela faz e como está estruturada. Para dar um passo adiante, gostaria de colocar LoginControllere LogoutControllerem área separada.

Eu desenvolvi algo assim antes e funcionou muito bem.

A maior parte do seu código estaria acontecendo em uma camada de negócios, certo? Se for esse o caso, tudo o que você realmente está fazendo no seu controlador é retornar dados para a visualização.

Não tenho certeza se sou fã de separar os controladores em subtipos. Enquanto você deve manter a separação de preocupações, acho que os subtipos estão indo longe demais. Além disso, você precisa ter cuidado nos casos em que objetos pesados ​​são inicializados no construtor ou em um controlador. Por exemplo: no seu exemplo, você deseja que um objeto pesado, usado apenas para a busca / upload de arquivo, seja liberado quando o usuário estiver na página de login.

É melhor ter um controlador por unidade lógica, por exemplo, AccountController (login, registro, logout), FileController (pesquisa, upload) e assim por diante.

Em geral, você pode dizer que todo modelo tem seus próprios CONTROLADORES e VISUALIZAÇÕES dedicadas. Ao dizer geral, quero dizer que esta é a melhor prática.

Aspectos do aplicativo (como gerenciamento de usuários) devem ser traduzidos para o serviço de aplicativo e precisam ser chamados pelo próprio controlador ou envolver o controlador (usando atributos que tornam a funcionalidade do controlador "visível" de acordo com a função de usuário solicitada, por exemplo).

Lembre-se de que todos os controladores devem lidar basicamente com operações CRUD sobre o modelo e usar visões diferentes para filtros diferentes.

Na minha opinião, uma das principais vantagens do MVC como padrão é que ele oferece a melhor maneira de vincular modelos e visualizações.

Sobre o exemplo que você adicionou: Eu criaria 2 controladores: um para a operação de login de todos os usuários (registro, login, logout etc.) e o segundo para operações de arquivo (Upload e pesquisa). observe que o primeiro também deve ter backup com algum aspecto relacionado à funcionalidade de login e o segundo é um controlador comum