Um controlador por página ou muitas páginas em um controlador?


16

Eu só queria alguns conselhos sobre o modo MVC de fazer as coisas. Eu estou usando o codeigniter e queria saber se é melhor ter um controlador por página para um site ou um controlador para todas as páginas?

Digamos que eu tenha um site simples, onde você pode visitar a página inicial, fazer login, criar uma conta e entrar em contato com o administrador.

  1. Seria melhor ter esses controladores: front-end (índice), logon, conta, contato OU ter um controlador chamado front-end ou qualquer outra coisa com as ações como logon, createAccount, contato?

  2. Quando você sabe se é melhor usar um controlador em uma situação?


Eu sempre vivi de acordo com o credo: um controlador para governar todos eles, e na escuridão amarre-os. (Não realmente, mas eu gosto do som dele :-).
Peter Rowell

Respostas:


16

É melhor ter um controlador por unidade lógica, por exemplo, AccountController (login, registro), PagesController (home, contato), Backend -> PagesController (criar, editar, excluir), UsersController (criar, editar, excluir) e assim por diante.


Como você representaria um site com essas áreas: casa, login, conta, contato. Você usaria 2 controladores como o seu exemplo? se você for para o host local / ele abrir o controlador de casa, se você for o host / contato local na teoria, ele não deve entrar em contato com o controlador? e o que você quer dizer com back-end?
Rushino

Depende de qual é a estrutura das páginas e quantas páginas você possui. Farei o HomeController (casa, contato) ou o PagesController (casa, contato OU detalhes (id)). Por exemplo, no ASP.NET MVC, você tem o HomeController padrão com a página Inicial e Sobre.
25711 Santas

Eu gosto deste método Também um ClientController (ou o que você quiser chamá-lo) para Ações chamado via Jquery.Ajax que não é específico a nenhuma parte específica do seu aplicativo. ou seja, reutilizáveis de qualquer um dos seus pontos de vista
Chris

Parece a resposta certa para mim. O CodeIgniter aceita subdiretórios para controladores que permitem separar os controladores em zonas para que eu possa terminar com dois controladores de páginas (um por zona). Obrigado!
Rushino

Mas você não acabaria com grandes controladores, mesmo que as ações sejam todas relativas? Ou isso não é problema?
Kid Diamond

4

@Rushino Você tem dois 'aplicativos' aqui - o front-end (para leitores) e o back-end (para administradores). Para cada grupo de funcionalidade, você tem um controlador.

O login é um grupo desse tipo, que inclui a geração do formulário HTML (os campos, chamando a visualização) e o tratamento do formulário (a validação, conectando-se ao modelo). Portanto, 'login' é um controlador com duas ações - generateForm e handleForm.

O Pages é dividido entre o aplicativo front-end - que apenas mostra as páginas - e o aplicativo back-end que permite editar, excluir, criar e possivelmente exibi-los de uma maneira diferente. A página inicial é "apenas mais uma página" no front-end, pelo que cabe no controlador de páginas. No back-end, sua lógica pode ser diferente o suficiente para justificar a existência de um controlador diferente.

Para usuários - se os usuários puderem se registrar, precisarão de um controlador de front-end, mas, se não, tudo a ver com os usuários ocorre apenas no back-end.

Observe que cada uma das funções de back-end pode exigir um gerador e um manipulador. Porém, essas coisas podem ser divididas em arquivos de configuração, com um plug-in que é um gerador de formulários genérico.

Em resumo, fica assim:

Frontend
  Pages
    View, Handle
  Login
    View, Handle
  Users
    Register (note that the handler can be the same as 'create' on the backend)
  Contact
    View
    Handle

Backend
  Users
    Create, Delete, Edit, Update, View
  Pages
    Create, Delete, Edit, Update, View

Espere .. você está dizendo que uma seção representa um aplicativo? maneira interessante de fazê-lo (e provavelmente a maneira de fazê-lo). Gostaria de saber se codeigniter fazê-lo desta maneira .. irá verificar. Devo ter certeza de que você pode ir de um aplicativo para outro sem interromper nenhum estado de sessão ou conexão.
Rushino

1
O @Rushino CodeIgniter pode fazê-lo desta maneira - você pode colocar pastas dentro do diretório Controladores. A distinção entre 'aplicativos' não está no nível do banco de dados / modelo, mas no nível do controlador / visualização. O motivo da separação é que seu back-end está fazendo coisas muito diferentes, geralmente com um design completamente diferente. Ajuda na segurança, porque você pode restringir o IP do diretório de back-end inteiro. E isso ajuda no desenvolvimento, porque você pode trabalhar no back-end sem afetar o front-end.
Dan Blows

2

Eu acho que você deve usar um Controller por unidade de negócios, como OrdersController para todas as operações relacionadas a pedidos e coisas do tipo. Estou ciente de que, nesse caso, os Controladores ficam ENORMES, mas ainda podemos usar classes auxiliares para delegar coisas como inicialização de modelo e classes parciais para espalhar ações em arquivos separados.

Por exemplo, posso ter Create.cs and OrdersControllerarquivos OrdersController List.cs para a classe OrdersController, cada um com o conjunto de ações correspondente. Torna as coisas muito mais limpas e ainda mantém as operações de pedidos centralizadas em uma única classe de controlador.

Apenas meus 2 centavos.


0

Eu acho que você poderia adotar uma abordagem diferente:

Um controlador principal como porta frontal que fornece solicitação para controladores específicos. Dessa forma, você pode usar esse controlador frontal para verificar coisas comuns, como autenticação do usuário, analítica do Google e outras coisas gerais que você gostaria de fazer e manter a estrutura do MVC pura.

Esta não é minha idéia, mas o Symfony Framework funciona dessa maneira, portanto, posso dizer que, pela minha experiência, essa é uma maneira muito agradável e elegante de implementar um front-end.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.