Estou “fazendo errado” em Kohana 3?

Question

Quando eu tenho um controlador, por ex.artigo, muitas vezes tenho um action_view() que lida com a maior parte do código.

Às vezes, pode ter de 80 a 100 linhas.

Meu controlador geralmente lida com tudo isso:

• variáveis ​​de modelo de ligação
• definir sessões (quando apropriado)
• enviar e-mails
• validando formulários

Pude ver aos poucos que poderia fazer outro método privado no controlador, não necessariamente para reutilização, mas para separação de interesses.

No entanto, parece estranho (para mim) ter métodos que podem ser chamados através de uma rota e métodos que são apenas internos.

Além disso, algumas coisas me dizem "Eu deveria estar no modelo, não no controlador".No entanto, também não tenho certeza se isso está correto.

No final, tenho um método de controlador um tanto gordo que parece bastante processual.

Devo realmente ter uma lista no topo da minha action_* métodos e depois separar o restante do meu código em módulos menores?

Tenho um exemplo abaixo...isso é típico de controlador ou as sessões, etc., deveriam estar no modelo?

public function action_pdf($type, $id) {

        // Get PDF file from db and send headers to it
        $id = (int) $id;

        $pdfFile = $this->model->getPdf($id, $type);

        if ($pdfFile) {
           $this->request->redirect($pdfFile);
        } else {
           $this->session->set('pdfMissing', true);
           $this->request->redirect(Route::get('properties')->uri());
        }

    }

Então, minha pergunta é: estou fazendo errado?

Answer 1

Seus modelos existem para encapsular a lógica de negócios e geralmente para abstrair a camada de armazenamento de dados do restante da arquitetura (controladores, visualizações).

O que isto significa é que qualquer acesso ao banco de dados (por exemploConsultas SQL) e tais devem idealmente estar contidos em seus modelos.Seu controlador obterá seus dados de seus modelos (isso inclui ORM, que se expõe por meio de modelos) sem precisar acessar o banco de dados diretamente.

No que diz respeito ao envio de e-mail, acho que depende da situação.Por exemplo, quando um usuário se inscreve eu chamo um método Model para inserir seus dados no banco de dados.Este método então aciona um e-mail a ser enviado a eles.Desta forma estou fazendo com que o envio do e-mail seja uma parte explícita da lógica de negócio de inscrição (e é isso que eu quero neste caso) para que não importa quem chame o método de inscrição no modelo, o sistema não esqueça para enviar um e-mail.

Quando se trata de validação de formulário, tento especificar a maioria das minhas regras de validação nas classes do modelo ORM.Isto ocorre para que não importa quem manipula o modelo, o modelo sempre tenha algum entendimento inerente de como validar seus próprios dados.E você notará que o objeto do modelo ORM já fornece um método para validar seus dados.Qualquer validação/retorno de chamada extra que o modelo não precise saber inerentemente pode ser feito fora do código do modelo.

Answer 2

IANAPHPD (I Am Not A PHP Dev), mas a perspectiva de um desenvolvedor de linguagem de programação geral (Java/C#) pode ser útil.Para mim, um dos benefícios do MVC é promover a reutilização de código quando você tem lógica e infraestrutura de negócios centrais que precisam ser apresentadas com múltiplas UIs.Por exemplo, um sistema de gerenciamento de pedidos que possui uma interface web e também uma interface desktop.Nesse caso, essa lógica central é o Modelo.Cada uma das três interfaces possui visualizações e controladores próprios.Em C#, é trivial estruturar seu código de forma que a lógica principal esteja em um conjunto de pacotes/assemblies que são referenciados em um projeto de UI de desktop, bem como em um projeto de aplicativo web.

Penso nesses termos, mesmo quando tenho certeza de que um aplicativo específico não precisará de outra IU.Quando estou tentando decidir se algo deve entrar no modelo ou no controlador, eu me pergunto se essa funcionalidade deve ser reutilizável em outra UI.

Esta é uma maneira pouco natural de pensar no código PHP, já que o PHP está fortemente vinculado à plataforma web (até onde eu sei).Independentemente disso, esta forma de pensar ainda se mantém (Separação de Preocupações e Não se Repita) ainda pode ser aplicada: uma "UI" secundária que o PHP poderia suportar seria uma API de serviço da web.Se um recurso estiver disponível para um site e uma API de serviço da web, ele deverá ser exposto no modelo.

Você pode ou não estar interessado, mas no geral, essa forma de pensar se integra perfeitamente ao Domain-Driven Design.

Observação:Embora todas as UIs suportadas pelo PHP sejam baseadas na web, eu ainda teria cuidado ao colocar preocupações específicas da web no modelo (qualquer coisa relacionada a sessões do navegador, cookies, rastreamento de acessos, etc.), principalmente porque essas preocupações são centradas na apresentação e não centrado nos negócios, e secundariamente porque isso torna mais difícil portar o sistema gradativamente para outro idioma/plataforma por qualquer motivo posteriormente.