Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

Prove Yourself

Minha implementação MVC

Recommended Posts

Mas João, vendo o exemplo de como eu faço minhas aplicações, da pra perceber que o controller é quem está decidindo o quê fazer com a ação do usuário, que logicamente, vem do view e, logo então, o controller faz a sua requisição com o DAO (que seria no model?! pelo menos sempre achei que o lugar do DAO é no model), e então o DAO manda uma resposta para o controller, que informa ao view o quê aconteceu com a requisição.

 

Ai é que está, veja:

 

da pra perceber que o controller é quem está decidindo o quê fazer com a ação do usuário, que logicamente, vem do view

Até ai perfeito, a view provê uma forma de o usuário interagir com a aplicação, então, de uma forma simplista, as requisições do usuário deverão vir dela.

 

logo então, o controller faz a sua requisição com o DAO (que seria no model?! pelo menos sempre achei que o lugar do DAO é no model),

 

Nesse ponto, o controller deve, de acordo com a requisição do usuário, chamar a model adequada. Quem irá utilizar a DAO é a Model e não a controller, a controller deve chamar a Model e essa irá utilizar ou não um DAO.

 

e então o DAO manda uma resposta para o controller, que informa ao view o quê aconteceu com a requisição.

 

Aqui é consequencia da anterior, como quem utiliza DAO é a model, é ela que trabalhará com os dados da DAO e, após receber esses dados a View será montada.

 

Perceba que você pode ou não ter uma DAO e é exatamente por esse motivo que quem decide se utilizará uma DAO é a Model e não o Controller e também por esse motivo que o Controller não deve receber os dados da DAO, a Model deve encapsular o acesso aos dados para que o Controller tenha uma interface conhecida para trabalhar independentemente de se utilizar acesso a dados ou não.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Aqui é consequencia da anterior, como quem utiliza DAO é a model, é ela que trabalhará com os dados da DAO e, após receber esses dados a View será montada.

 

Perceba que você pode ou não ter uma DAO e é exatamente por esse motivo que quem decide se utilizará uma DAO é a Model e não o Controller e também por esse motivo que o Controller não deve receber os dados da DAO, a Model deve encapsular o acesso aos dados para que o Controller tenha uma interface conhecida para trabalhar independentemente de se utilizar acesso a dados ou não.

 

Bom, eu devo estar me expressando mal então, vendo na prática... olhando os meus códigos que eu postei ai nesse post... está certo a logica de estrutura MVC que eu utilizei????

 

Talvez eu esteja confundindo os nomes, eu não sei, talvez eu não sei ao certo o que é a Model e o que é a DAO (na prática)...

 

Para mim, a DAO é uma classe que faz parte da Model, como a que eu citei neste post, veja:

 

 

require('../../libs/Conexao.php');
require('../to/UsuariosTO.php');

class UsuariosDAO extends UsuariosTO
{
             var $con;

             function __construct()
             {
                          $conDAO = new ConexaoDAO;
                          $this->con = $conDAO->pdo;
             }

             function Inserir() {
                          $registro = array {
                                       'user'=>$this->getUser(),
                                       'pass'=>$this->getPass()
                          };
                          $prepara = $this->con->prepare('INSERT INTO usuarios (user, pass) VALUES (:user, MD5(:pass))');
                          $execute = $prepare->execute($registro);
             }

             function Selecionar() {
                          $registros = $this->con->query('SELECT id, user, pass FROM usuarios')->fetchAll();
                          return $registros;             
             }
}

 

Para mim, isso é a DAO que está fazendo a parte "M" do MVC.

 

Abraços

Compartilhar este post


Link para o post
Compartilhar em outros sites

Para mim, isso é a DAO que está fazendo a parte "M" do MVC.

Perfeito, hehehe

 

Estamos falando então a mesma coisa, isso ai é uma DAO.

 

Tudo se resume a CRUD, os dados na tabela do banco de dados possui uma hierarquia diferente de quando falamos em OOP, por isso se faz necessário implementar um ORM.

 

A DAO provê uma interface para se criar, ler, atualizar e excluir os dados do banco, o objetivo dela é abstrair o acesso real aos dados no banco de forma que você possa modificá-lo sem comprometer a aplicação; Ela é utilizada pela Model para ler/gravar os dados do banco utilizando objetos para isso, tanto na entrada quanto na saída.

 

;)

Compartilhar este post


Link para o post
Compartilhar em outros sites

EUHEUHUEHEUH... ok, ok!!!

 

Então pelo visto, não precisarei refazer minhas aplicações de base =).

 

Talvez eu não esteja no fim do arco-íris com o baú aberto recolhendo meus ouros, mas esteja na metade do caminho. (by eu mesmo :D).

 

Mas ainda bem que eu não estou viajando tanto...

 

Então, mas talvez eu esteja fazendo uma estrutura de diretórios meio diferente, porque estou acostumado com JAVA, trabalhei muito com o MVC mas no JAVA na faculdade... e talvez acabei me acostumando com a estrutura dele e estou utilizando-a no PHP.

 

Mesmo assim, pretendo aprender o Zend Framework, pois já li alguns posts sobre ele e achei muito interessante e enxuto.

 

Muito obrigado pelas explicações João Batista, ampliei meus conhecimentos no MVC neste post, obrigado!

 

Lucas Martins

Compartilhar este post


Link para o post
Compartilhar em outros sites

porque estou acostumado com JAVA, trabalhei muito com o MVC mas no JAVA na faculdade... e talvez acabei me acostumando com a estrutura dele

hehehe, /servlet demonstrou isso.

 

;)

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.