MVC… como e por que, e que outras boas opções existem (PHP)?

StackOverflow https://stackoverflow.com/questions/1552607

Pergunta

Todos os exemplos que vi sobre o que e como o MVC DEVE ser usaram classes como modelos, classes como controlador e modelos HTML como visualização.E todos eles consistiam em um script index.php e diferentes solicitações na url para executar todo o site.

Então todos eles foram algo como...

MODEL
class User{
    function getUser($userID){
      $sql = mysql_query('SELECT name......');
      // more code.....
      return $array
    }
}

VIEW
<h2><?php echo $user['name']; ?></h2>

CONTROLLER
class Controller{
    $userModel = new User;
    $userInfo = $userModel->getUser($id);

    $template = new Template('usertemplate.tpl');
    $template->setVariables($userInfo);
    $template->display();
}

Entendo por que o modelo é feito de classes que simplesmente obtêm e salvam dados (embora eu assuma que as classes nem sempre são necessárias e que funções podem ser usadas).Entendo por que o modelo consiste principalmente em HTML.Mas não entendo porque o controlador é uma classe.Eu presumiria que o controlador fosse um script processual (como userprofile.php que obtém os dados dos usuários do modelo e os envia para o modelo para exibição).

Além disso, eu queria saber por que cada tutorial que li tratava da reescrita de mod e do uso de uma única página com solicitações no URL como "index.php?user=1" ou index.php?news=3 para executar o todo site.O que há de errado em ter páginas separadas como user_profile.php?id=1 ou news.php?id=3...

Alguém pode me ajudar com um rápido "tutorial" e uma explicação ao longo do caminho.Tipo... como um formulário de registro seria implementado usando MVC, o que iria para onde e por quê?obrigado

PS.que outros tipos de padrões de design existem

Foi útil?

Solução

A grande "vitória" do controlador na versão MVC do PHP é que você evita ter uma página PHP separada para cada URL à qual seu aplicativo responde.

Quando você cria uma nova página única para cada URL, espera que seus desenvolvedores (ou você mesmo) obtenham as bibliotecas necessárias e inicializem o mecanismo de modelo/layout da mesma maneira.Mesmo quando você é um único desenvolvedor, a tentação de romper com a maneira "padrão" de fazer as coisas geralmente acaba sendo muito forte, o que significa cada URL/página PHP acaba sendo seu próprio mini-aplicativo em vez de cada URL/página PHP fazer parte do mesmo aplicativo.Quando você tem vários desenvolvedores, é garantido que isso aconteça.

O resultado final são páginas e componentes que não funcionam bem uns com os outros e são difíceis de depurar (com tudo pendurado no namespace global), proporcionando uma experiência inconsistente tanto para os usuários quanto para os desenvolvedores que precisam trabalhar no projeto .

As estruturas MVC também facilitam o fornecimento de URLs amigáveis ​​ao seu site.Geralmente há coisas suficientes acontecendo no sistema de roteamento que você não precisar recorrer a um grande número de variáveis ​​de string de consulta.URLs legíveis são uma vantagem para SEO e para usuários experientes.

Finalmente, embora isso seja uma ilusão para a maioria das lojas, quando você tem um controlador, os métodos no controlador tornam-se facilmente testáveis ​​em unidade.Embora você possa tecnicamente envolver um equipamento de teste em um site não MVC, é sempre um pé no saco e nunca funciona como você gostaria.

Outras dicas

Usando uma única página com solicitações no URL como "index.php? User = 1" ou index.php? News = 3 para executar o site inteiro.O que há de errado em ter páginas separadas como user_profile.php? Id = 1 ou news.php? Id = 3 ...

Usar um único ponto de entrada facilita algumas coisas, suponho:

  • Você não precisa duplicar nenhuma parte do código em user_profile.php e news.php
  • Se você deseja configurar qualquer tipo de filtro (como PHPIDS para segurança, ou ACL, por exemplo), você só tem um arquivo para modificar, e isso é feito para toda a aplicação.

PS.Que outro tipo de padrões de design existem

Existem muitos padrões de design;você pode encontrar uma lista no Padrão de design (ciência da computação) artigo na Wikipédia, por exemplo - com links para a página de cada um deles, para mais detalhes.

Não há nada de errado em ter scripts separados para cada ação, e na verdade você PODE criar uma arquitetura MVC desta forma, sem usar uma classe para o controlador.No momento, estou trabalhando em uma estrutura MVC que suporta ambos os estilos.

O importante é realmente manter a separação das diferentes preocupações.A lógica do banco de dados entra nos seus modelos, a lógica do layout entra nos modelos e tudo mais no controlador.

Então, para um exemplo realmente simples, você poderia ter um script "register.php" com o seguinte código

$signup_options = SignupOptions::getSignupOptions(); // Load some data      
require("register_form.php");  // Pass it to the view

E isso posta em Register_process.php

$username = $_REQUEST['username'];
$password = $_REQUEST['password'];
$email    = $_REQUEST['email'];
Users::Register( $username, $password, $email );
header( 'location: register_success.php' );

O MVC não é adequado para todos os aplicativos, portanto, você deve considerar sua arquitetura por projeto.Para muitos sites, apenas ter vários scripts independentes funciona bem.No entanto, para aplicações maiores e mais complexas, o MVC provou ser uma forma confiável e escalável de desenvolver aplicações web.

Outro padrão de design comum é "View-Helper", onde você chama um modelo diretamente, e o modelo chama um objeto "Helper" que executa a lógica de negócios entre o modelo e os modelos.Semelhante em conceito, mas você pode ignorar qualquer código extra para modelos que não precisam dele, mantendo a separação de preocupações como MVC.(A diferença é essencialmente que você chama o modelo diretamente, em vez de chamar um controlador).

Existem diversas maneiras de implementar uma boa aplicação, mas vou apenas abordar alguns conceitos.Esses conceitos são retirados do Samstyle PHP Framework.

Em primeiro lugar, você tem estes componentes:Modelo (Gateway de dados de tabela), Visualização, Controlador de visualização e Controlador de back-end.

Este View Controller realmente controla como será a visualização (por exemploexibir o formulário de inscrição).O Backend Controller processa os dados do usuário no backend e interage com o Modelo (banco de dados).

Então aqui podemos integrar facilmente Pós-redirecionamento-obter afim disso.

Diga que você tem registrar.php para o View Controller que exibirá o formulário e analisará o conteúdo no arquivo HTML do modelo.

O usuário usa o formulário, envia e será postado no Backend Controller deck.php.O Backend Controller valida, verifica e depois passa os dados para funções (Table Data Gateway) que irão ajudá-lo a interagir com o banco de dados.Após a interação, o usuário é redirecionado para uma página de sucesso ou para uma página de registro com erro.

No modelo (Table Data Gateway), você realmente tem funções que recebem um array e depois CRUD com o banco de dados.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top