MVC Architecture - Quantos Controladores eu preciso?

Para o seu exemplo, eu criaria dois controladores:

• Sessions Controller para Login e Logout (criar e destruir sessão para REST como layout)
• Controlador de arquivos para tudo em arquivos (índice = search e create = upload)

Em geral, uma abordagem RESTful em que você pensa em tudo como um recurso que pode ser exibido, criado, editado e destruído, dá a você 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 precisaria de mais controladores para obter mais funcionalidades. Por exemplo, um controlador de usuários, onde os usuários podem criar novas contas. Além disso, você precisará 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 ideia inicial pode ser um controlador para cada tabela em seu banco de dados que os usuários podem acessar. Mas isso é realmente apenas uma medida muito grosseira.

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

Se o seu controlador sofre de um ou mais código cheira (especialmente Grande Classe ou Objeto Divino ), então você sabe que provavelmente está além do ponto em que apenas um fará.

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

Uma regra geral , o número de controladores necessários depende de vários módulos e sub-módulos no aplicativo da Web.

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

Existem várias discussões relacionadas:

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

Eu gosto da maneira da Apple de fazer isso.

Every view is controlled by only one view controller. ~View Controller Programming Guide for iOS

A ideia é que você seja capaz de trocar facilmente Views. IMO, por ter apenas 1 Controller por View , torna mais fácil conseguir isso. Mas tenho certeza que você poderia ter um controlador com múltiplas visualizações e ainda projetá-lo para que você possa alternar as visualizações sem alterar a lógica do programa.

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

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

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

Controller - O dial, onde você altera a temperatura

Modelo - As partes internas que são invocadas pelo controlador que alteram a temperatura.

Você deve sempre obedecer a projetos que permitem o baixo acoplamento e limitar os modelos e seus controladores associados a uma única tarefa , e você deve usar quantos módulos / controladores você precisar . Dependendo do tamanho do seu aplicativo, você pode ter muito menos visualizações do que os modelos e controladores. Isso é esperado com qualquer aplicativo de tamanho grande. A boa programação orientada a objetos é caracterizada por baixo acoplamento, encapsulamento, herança e polimorfismo. Nem todas as linguagens suportam o polimorfismo com o mesmo grau (função, método, sobrecarga de operador / overriding).

Se você quiser ter um melhor entendimento de como empregar a arquitetura MVC adequadamente, consulte o GoF "Design Patterns: Elementos de software reutilizável ...", que usa código C ++ e SmallTalk, por exemplo. Este livro não é o alfa e o ômega, mas certamente é um começo!

Boa sorte!

Presumo que o seu exemplo evolua para um sistema complexo.

Aplicação:

O usuário faz login:

• LoginController

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

Envie um arquivo

• UploadController

Suponho que você queira fazer upload de qualquer tipo de arquivo. Se em data posterior você decidir fazer o upload de MP3s e PDFs, então eu teria uma base UploadController, MP3UploadController e PDFUploadController.

Procure por um arquivo.

• SearchFileController

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

Logout.

- LogoutController .

Alguém pode considerar isso como um exagero, mas não acho que seja. Eu acho que é limpo e bem separado.

Se eu olhasse para essa estrutura de projeto, saberia instantaneamente o que ela faz e como está estruturada. Para dar um passo adiante, colocaria LoginController e LogoutController em uma á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 os dados para a exibição.

Não tenho certeza se sou fã de separar os controladores em subtipos. Embora você deva manter a separação de interesses, 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ê desejaria um objeto pesado, usado somente para o arquivo de pesquisa / upload a ser lançado quando o usuário estivesse 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 visões dedicadas. Ao dizer geral, quero dizer que esta é a melhor prática.

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

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

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

Sobre o exemplo que você adicionou: Eu criaria 2 controlador: 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 ser feito com algum Aspecto relacionado à funcionalidade Login e o segundo é o controlador comum