Qual é a finalidade da pasta Model do framework Inphinit? – php inphinit

Pergunta:


No Inphinit micro-framework existe a pasta Model que fica dentro da pasta application, e nela é onde ficam as classes, mas eu estou muito confuso em relação a essas classes.

Veja uma classe dentro da pasta Model:

<?php
namespace Model;

class User extends InphinitExperimentalModel
{
}

Dúvidas

  1. Eu gostaria de saber qual é a finalidade da pasta Model?
  2. Para que serve as classes da pasta Model e qual a importância que
    essas classes tem em relação ao funcionamento da minha aplicação Web?

Se puder me explicar com exemplos práticos vai ser mais fácil para eu entender.

Autor da pergunta gato

Eu gostaria de saber qual é a finalidade da pasta Model?

Normalmente em aplicações web utilizamos uma forma de organização do projeto chamada MVC. (Model-View-Controller)

  • Model Classes relacionadas a banco de dados e regras de negócio

  • View Templates com HTML/Linguagem de template para visualizar o conteúdo da sua aplicação.

  • Controller Classes que fazem o controle da aplicação. É como se fossem uma cola entre os modelos e as views. É geralmente nos controllers que a aplicação verifica se é um GET,POST, etc e toma as decisões sobre qual View mostrar, como processar os dados, etc.

Para que serve as classes da pasta Model

Neste modelo de organização as classes que correspondem as regras de negócio e ligação com o banco de dados costumam ficar na pasta Model.

É uma forma de organização e você pode optar por segui-la ou não.

e qual a importância que essas classes tem em relação ao funcionamento da minha aplicação Web?

A importância dos modelos é deixar mais claro e separado as regras de negócio e de banco de dados do restante da aplicação.

Atualmente o MVC é muito utilizado em frameworks, apesar de eu nunca ver uma estrutura exatamente igual ou padronizada. Isto serve mais como uma linha de guia para manter a organização, mas você sempre é livre para mudar e usar conforme a sua necessidade.

O jHertel já deu uma breve introdução ao que é o MVC, algumas perguntas que podem lhe ajudar sobre isto especificamente:

Do meu ponto de vista resumido, MVC não tem um padrão especifico, na verdade de muitas maneiras você pode fazer o uso disto e atingir o mesmo resultado, podendo ser estrito ou não, o inphinit não é estrito (rigoroso), na verdade é bem “livre”, com exceção dos Controllers que quase sempre são obrigatórios (apesar de suportar Closures).

Então o MVC é um modo de se organizar e não uma tecnologia, do meu ponto de vista, o MVC mais comum representado é este:

mvc

O inphinit segue muitas coisas semelhantes a outros frameworks conhecidos, tendo a pasta e namespace para Controller e Model (View não tem namespace), esta classe que você postou foi um dos exemplos experimentais que estava realizando:

<?php
namespace Model;

class User extends InphinitExperimentalModel
{
}

No momento removi a classe InphinitExperimentalModel, não por ser errado, mas por não atingir ainda o que espero, do meu ponto de vista Models não tem nada haver com banco de dados, eles apenas usam os dados contidos neles, o objetivo do Model é definir as “regras de negócio”, fazendo uso assim de qualquer tipo de informação, tendo a capacidade de obtê-las, atualizar e deletar, mas tudo isso tendo regras.

No entanto creio que um Model, seja aonde for nunca deve manipular coisas diretamente, tipo enviar dados para o ouput, ou enviar resposta, ele deve enviar apenas a resposta (se houver) para o controller e o controller deve se encarregar do resto (claro que me baseio nisto com a experiencia que tive com ferramentas totalmente diferentes, como disse MVC nem sempre é igual em dois lugares ou frameworks diferentes).

Na maior parte dos frameworks que noto o Model é usado meramente como instrumento de conexão com o banco e algumas regras acabam caindo dentro do Controller.

Quando idealizei o inphinit ele tinha 5 objetivos:

  1. Suportar o PHP 5.3
  2. Gastar o minimo de memória possível
  3. Ser o mais rápido possível sem existir inúmeros ciclos dentro do núcleo.
  4. Ser mais simples possível para o aprendizado
  5. Suportar bibliotecas de terceiros (3rdparty) que seja instalado via composer

Com este último objetivo é que chegamos ao namespace Model; e a pasta system/application/Model/, o framework não possui nada como migration, conexão e sqlbuilder, mas isto não quer dizer que você não possa instalar coisas de terceiros, existem frameworks que inclusive já usei com ele como:

Ou seja o foco da pasta e namespace Model é o mesmo que da maioria dos frameworks, no entanto pode-se usar com o ORM que desejar ou como desejar

Assim que possível irie adicionar um passo-a-passo de um ou mais frameworks para trabalhar com o namespace Model.

Fonte

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *