Qual seria o meu controlador de estar nestes cenários em uma aplicação web MVC?

Question

1) Onde é que a página inicial do seu site se encaixam em "controladores"? Eu vi algumas pessoas usam um controlador de "página" para lidar com páginas estáticas, como, sobre, casa, contato, etc., mas para mim isso não parece ser uma boa ideia. Será que a criação de um controlador distinto apenas para sua página ser uma opção melhor? Afinal, ele pode precisar de vários modelos de acesso e realmente não fluir bem com o todo, um controlador por teoria dos modelos que algumas pessoas usam.

2) Se você precisa de um painel para vários tipos de usuários, teria que ser um controlador de painel que teria de alternância dependente de qual usuário código, ou você teria dizer uma ação dashboard dentro de cada controlador por usuário? Por exemplo, admin / dashboard, conta / painel, etc.

3) Parece-me que o uso de toda a exemplo simples CRUD funciona como um encanto quando se tenta explicar controladores, mas que depois de passar por essas funções simples, se decompõe e pode fazer com que seus controladores para obter pesado. Por que algumas pessoas escolhem para criar um controlador de login, quando os outros fazer uma função de login em um controlador de usuário? Uma razão que eu acho é que muitos de nós vêm de um fundo abordagem página e é difícil pensar em controladores como "objetos" ou "substantivos" porque as páginas nem sempre funciona assim. Caso em questão porque na terra você iria querer criar um "páginas" controlador que iria lidar com páginas que realmente não têm nada a ver com o outro apenas para ter um "container" para caber ações em. Apenas não parece certo para mim.

4) controladores deveria ter mais a ver com um caso de uso de um "objeto" que as ações podem ser executadas em? Para todos os efeitos intensivos, você pode criar um controlador de usuário que faz cada ação em seu aplicativo inteiro. Ou você pode criar um controlador por "área de interesse", como alguns gostam de dizer. Ou você pode criar um controlador per view se você queria. Há muito espaço de manobra que o torna difícil de descobrir um método consistente para uso.

Controllers não deveria ser tão confuso provavelmente, mas por algum motivo eles confundir o inferno fora de mim. Quaisquer comentários úteis seria muito apreciada.

Answer 1

1) Eu uso um conjunto homebrew simples de classes para algumas das minhas coisas MVC, e relaciona nomes de controladores para nomes de ação e de visualização (é um estilo Front Controller, semelhante ao Zend). Para um site genérico, vamos assumir que tem uma home page, política de privacidade, página de contato e um sobre a página. Eu realmente não quero fazer controladores separados por todas estas coisas, então eu vou colocá-los dentro da minha IndexController, com nomes de funções como actionIndex(), actionPrivacy(), actionContact() e actionAbout().

Para ir junto com isso, dentro do meu diretório Visualizações Eu tenho um diretório de modelos associados a cada ação. Por padrão, qualquer ação automaticamente procura por um modelo associado, embora você pode especificar um se quiser. Então actionPrivacy() iria procurar um arquivo de modelo na index/privacy.php, actionContact() iria procurar index/contact.php, etc.

É claro que isso se relaciona com as URLs também. Assim, um url bateu para http://www.example.com/index/about correria actionAbout(), que iria carregar o Sobre modelo de página. Desde o sobre a página é o conteúdo completamente estática, meu actionAbout() não faz absolutamente nada, que não fornecem uma ação pública para o Front Controller para ver e correr.

Então, para responder o núcleo da sua pergunta, eu não colocar várias "páginas" em um único controlador, e ele funciona muito bem para os meus propósitos. Um modelo por controlador é uma teoria Eu não acho que eu tento seguir quando se trabalha com Web MVC, como parece caber uma aplicação com estado muito melhor.

2) Por isso, eu teria vários controladores. Seguindo os mesmos métodos que eu uso acima, eu teria /admin/dashboard e /account/dashboard como você sugere, embora não há nenhuma razão que não poderiam usar o mesmo (ou partes dos mesmos) modelos.

Suponho que se eu tinha um zilhão diferentes tipos de usuários, eu faria as coisas mais genérico e usar apenas um controlador, e tem uma regra mod_rewrite para lidar com a carga. Ele provavelmente vai depender de como funcionalmente complexa do painel de instrumentos é, eo que a conta criada é semelhante.

3) eu encontrar funcionalidade CRUD difícil de implementar directamente em qualquer camada do MVC e ainda ter que ser limpo, flexível e eficiente. Eu gosto de funcionalidade abstrato CRUD para fora em uma camada de serviço que qualquer objeto pode invocar, e ter uma classe de objeto de base a partir do qual posso estender quaisquer objectos que necessitam CRUD.

Gostaria de sugerir utilizando alguns dos quadros PHP ORM lá fora para CRUD. Eles podem acabar com um monte de problemas de se locomover uma boa implementação.

Em termos de controlador de login contra controlador de usuário, eu acho que depende do seu domínio de aplicação. Com o meu estilo de programação, eu tenderia a pensar em "entrando" como uma operação simples dentro do domínio de um modelo de usuário, e desta forma têm uma única operação para ele dentro de um controlador usuário. Para ser mais preciso, eu teria a UserController instanciar um modelo de usuário e chamar uma rotina de login do modelo. Eu não posso dizer-lhe que esta é a maneira correta, porque eu não poderia dizer com certeza que a maneira correta é suposto ser. É uma questão de contexto.

4) Você está certo sobre a margem de manobra. Você poderia facilmente criar um controlador que trataram de tudo a sua aplicação / site queria fazer. No entanto, penso que você concordaria que este se tornaria um pesadelo de manutenção. Eu ainda obter os jibbly-jibblies pensando em meu último emprego em uma empresa de pesquisa de mercado, onde o aplicativo PHP interna foi feito por uma equipe no exterior com o que eu só posso supor que era pouco ou nenhum treinamento. Estamos falando de 10.000 scripts de linha que manipulados todo o site. Era impossível de manter.

Então, eu sugiro que você quebrar seu aplicativo para baixo / site em áreas de domínio de negócio, e criar controladores com base nisso. Descobrir os conceitos fundamentais do seu aplicativo e de lá ir.

Exemplo

Vamos dizer que eu tinha um site sobre peixes-boi, porque, obviamente, peixes-boi rock. Eu quero algumas páginas do site normais (cerca de, contato, etc.), gestão de conta de usuário, um fórum, uma galeria de imagens, e talvez um documento de pesquisa da área de material (com a ciência mais recente sobre peixes-boi). simples bonita, e um monte de que seria estático, mas você pode começar a ver o colapso.

IndexController -. pegas cerca de página, política de privacidade, conteúdo estático genérico

UserController - alças a criação da conta, o login / out, preferências

PictureController - imagens de exibição, os envios punho

ForumController -. Provavelmente não muito, eu ia tentar integrar um foro externo, o que significa que eu não precisaria de muita funcionalidade aqui

LibraryController - mostrar listas de notícias e pesquisas recentes

HugAManateeController - abraços peixe-boi virtual em tempo real através de HTTP

Isso provavelmente lhe dá pelo menos uma separação básica. Se você encontrar um controlador de tornar-se extremamente grande, provavelmente é hora de quebrar o domínio do negócio em controladores separados.

Será diferente para cada projeto, portanto, um pouco de planejamento vai um longo caminho no sentido de que tipo de estrutura arquitectónica que você terá.

Web MVC pode ficar muito subjetiva, pois é muito diferente de um modelo MVC em que a sua aplicação tem estado. Eu tento manter grande funcionalidade fora de Controladores quando se lida com aplicativos web. Eu gosto deles para instanciar alguns objetos ou modelos, executar um par de métodos baseados na ação que está sendo tomada, e recolher algumas Visualização de dados para passar para a vista, uma vez que é feito. Quanto mais simples melhor, e eu coloquei à lógica do núcleo de negócios para as modelos, que são supostamente para ser representativa do estado da aplicação.

Espero que ajude.