MVC Architecture - Quantos Controladores eu preciso?

50

Eu tenho codificado há algum tempo, mas principalmente scripts e aplicativos simples. Eu me mudei para uma nova função, onde tudo se resume a desenvolver Web Apps e usar uma arquitetura MVC adequada, então estou desesperadamente tentando aprender tudo isso muito rapidamente.

Espero que esta pergunta não seja muito semelhante a " Práticas recomendadas para a arquitetura MVC

Quantos controladores um único aplicativo da Web precisa?

Sei que isso seria difícil de responder sem um exemplo, então eu fornecerei um:

Aplicação:

  1. Login do usuário.
  2. O usuário pode fazer uma destas três ações:
    a) Fazer upload de um arquivo (armazenado em um banco de dados mongodb com metadados). b) para um arquivo.
    c) Saia.

Minha pergunta é geral, mas eu dei o exemplo para ajudar alguém tentando responder.

    
por Jeff 13.08.2013 / 15:03
fonte

8 respostas

33

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.

    
por 13.08.2013 / 15:21
fonte
6

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á.

    
por 13.08.2013 / 15:18
fonte
5

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:

por 13.08.2013 / 15:54
fonte
4

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.

    
por 13.08.2013 / 16:05
fonte
2

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!

    
por 10.10.2013 / 09:53
fonte
1

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.

    
por 20.08.2013 / 14:37
fonte
1

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.

    
por 20.09.2013 / 00:39
fonte
0

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

    
por 20.08.2013 / 00:47
fonte