Métodos Mágicos e MVC

[Guilherme_90 33]

Bom dia iMasters. Bom,venha tirar umas dúvidas (pra variar).

 

1º - O método mágico __autoload() é recomendado para o carregamento automático das classes? Caso negativo, porquê?

2º - Estou desenvolvendo com MVC e DAO. Beleza, agora que vem um "problema". Vamos supor um cenário para melhor compreensão.

 

Tenho uma tabela que lista todos os estados. Porém, pra eu seguir o meu padrão de desenvolvimento, preciso criar o Model (set, get), DAO (persistência dos dados) e Controller. Mas, eu não vejo a necessidade de fazer essas 3 "fases", pois se eu for listar os estados por exemplo, vou jogar dentro de um select (HTMl), obter o id e inserir em outra tabela.

 

Vocẽs acham que estou fazendo certo em criar o MVC do Estado, ou seria interessante criar um método específico em determinada classe para listar os estados?

[Bruno Augusto 417]

Vou responder só a primeira, a segunda não entendi muito bem.

 

__autoload() antes de ser um método mágico, ele é um método e, por isso, passível de ser sobrescrito.

 

Se você desenvolver um sistema que servirá de base para o desenvolvimento de outros, ao usar __autoload() no sistema derivado, você deixa de poder utilizar o auto carregamento no sistema base, pois um sobrescreverá o outro.

 

A solução é utilizar spl_autoload_register(), que cria uma pilha de autoloaders permitindo que todos sejam utilizados.

 

Mesmo que você tenha apenas um sistema, que não derive de nenhum outro, o uso da SPL ainda é recomendado pois se um dia precisar de algum componente orientado a objetos e este também se utilizar de __autoload(), um vai anular o outro.

[Guilherme_90 33]

Bom, eu utilizo o __autoload sempre, pois não sabia as outras formas de carregamento dinâmico de classes.

Sobre a segunda dúvida, vou tentar explicar melhor, ou mais simples possível.

 

Quando desenvolvemos utilizando o padrão MVC, em todos os tipos de circunstâncias eu PRECISO criar um Model, DAO e um Controller? Pois tem casos em que não utilizarei para imprimir determinados dados, ou passar ação (insert, update, delete) em uma view por exemplo. Supondo o seguinte:

 

Tenho uma tabela de Cidades, certo? Então, seguindo essa idéia, eu PRECISO NECESSARIAMENTE criar um Model (set e get), DAO (persistencia de dados) e Controller, sendo que o máximo que irei fazer com esta tabela Cidades, é listá-las em um SELECT OPTION (HTML)? Tem mesmo que dar essa volta TODA (para seguir o padrão do sistema), ou seria melhor criar um método específico em determinada classe para listar as Cidades?

[Bruno Augusto 417]

Lista de dados imutáveis, se não estiverem passíveis em nenhuma hipótese de localização podem ser armazenados numa propriedade estática de uma classe abstrata.

 

Um bom exemplo, que aconteceu comigo, que quando aconteceu não quis entrar em detalhes, foi com relação aos MIME Types dos arquivos/conteúdo de páginas.

 

Quando desenvolvia a minha HTTP Request e Response e cheguei na parte de manipular os Headers, os quais precisavam de validação e, dentre tantos, alguns deles tinham, como integrantes dos possíveis valores (ou parte deles com base na RFC que os regulamentava), os MIME Types.

 

E a lista, principalmente da parte application, é ENORME! :o

 

Vasculhei as páginas do IANA, peguei a lista em HTML, copiei pra um dummy script, analisei sintaticamente, limpei, montei a estrutura e criei essa classe a qual é usada em várias validações, de vários Headers diferentes.

 

Com base no seu exemplo, uma lista de cidades pode parecer algo traduzível, mas não é, afinal não se traduzem Nomes Próprios.

 

João Pessoa (PB) vai ser João Pessoa em qualquer lugar do mundo e não John Person nos EUA ou Juan Persona na Espanha.

[visitante_php 0]

primeiro você nao esta fazendo MVC, você esta fazend 5 tiers, no 5 tiers o model se desdobra em bean, com get e set, o dao e o action, com as regra de negocio, ae vem o view e o controller...

 

eh recomendado sim o __autoload, mas eu pessoalmente acho q o auto load seria mais pro php4, no php5 da pra fazer uma classe simples de auto carregamento das outras...

 

eu PRECISO criar um Model, DAO e um Controller?

veja q o model e o dao fazem a mesma coisa, outra no seu mvc e nao vejo o view, ele morreu?

[Guilherme_90 33]

Bom, eu não entendi bufunfa nnehuma que o Bruno Augusto disse, e nenhuma das respostas respoderam minha pergunta. :cry:

[Bruno Augusto 417]

Eu desviei o foco um pouquinho na última resposta exemplificando com um caso muito particular à minha aplicação.

 

Vou tentar detalhar sendo específico apenas a nível do seu exemplo.

 

DAO, Data Access Object, Objeto de Acesso a Dados.

 

Esse objeto, instância de uma classe, acessa, retorna ou acessa e retorna informações, não importa de onde elas vêm.

 

Banco de Dados, XML, Arquivos de Texto, Array/Objeto, JSON, via Web... Via de regra você pode ter um DAO para cada tipo. A Orientação a Objetos te ajuda, com classes abstratas, por exemplo, quando diferentes DAO's apresentam características em comum.

 

Diferentes origens de dados estão associadas à diferentes necessidades. Porém, num nível mais básico, dos citados, todos exceto o Array/Objeto tem por objetivo armazenar a coleção de dados na memória em uso pelo interpretador para que a aplicação possa utilizar.

 

Por melhor que seja sua modelagem e suas classes de acesso às informações, elas jamais serão mais rápidas do que um array PHP, nem com a APC (cache), isso porque o array já está na memória, então todo intermediário foi eliminado e com isso a performance foi melhorada.

 

Sendo assim, se sua lista de informações é finita ou tem uma baixa taxa de atualização, no sentido de adicionar/remover registros, você não precisa de nada mais do que um simples array.

 

O exemplo das cidades ficaria mais ou menos assim:

 

<?php

abstract class Brazil{

   private static $states = array(

       'SP' => 'São Paulo',
       'MG' => 'Minas Gerais'
   );

   private static $cities = array(

       'SP' => array( 'São Paulo', 'Campinas', 'Ipiranga' ),
       'MG' => array( 'Itajubá', 'Varginha', 'Ouro Preto' ),

       // ...
   );
}

Mesmo que gigante, afinal são o quê? 5600 cidades no Brasil, é uma lista finita com uma baixíssima atualização, que ocorreria apenas no caso de cidades pequenas crescerem e justificarem delimitação territorial, que não vem ao caso.

 

Para melhorar a estrutura, as cidades estão armazenadas em um array multidimensional, classificadas por Estados.

 

E com os getters é que uma de suas muitas DAO's começa a atuar realmente como uma, seja para obter todas as cidades, todos os Estados, cidades de um Estado e etc.

 

Vejamos como ficaria:

 

<?php

abstract class Brazil{

   const SP = 'São Paulo';
   const MG = 'Minas Gerais';

   private static $cities = array(

       'SP' => array( 'São Paulo', 'Campinas', 'Ipiranga' ),
       'MG' => array( 'Itajubá', 'Varginha', 'Ouro Preto' ),

       // ...
   );

   public static function getStates() {

       $reflector = new ReflectionClass( 'Brazil' );

       return $reflector -> getConstants();
   }

   public static function getCities() {
       return self::$cities;
   }

   public static function getCitiesFromState( $state ) {

       $state = strtoupper( $state );

       if( ! defined( sprintf( 'self::%s', $state ) ) || ! array_key_exists( $state, self::$cities ) ) {
           throw new InvalidArgumentException( sprintf( 'Estado %s não existe', $state ) );
       }

       return self::$cities[ $state ];
   }
}

Se sua aplicação exigir dados, você vai ter uma DAO. Mas nem toda DAO terá setters, porém getters é quase certo que todas terão.

 

Se esses dados tiverem atualizações constantes, você precisa de um banco de dados até mesmo para garantir a integridade das informações.

 

Se não, KISS (Keep it simple, stupid). Pra que armazenar num banco de dados uma coisa útil mas tão trivial que um simples array resolve?

 

Melhorou? Se ainda achar que não, explique onde ainda reside a dúvida.

[Guilherme_90 33]

Bruno Augusto

Me desculpe pela minha "ignorancia" em tentar entender sua primeira resposta, mas as vezes algo simples que eu não consigo ver, ou meu cérebro trava! :ermm:

Mais então, no meu exemplo, tenho é uma tabela no banco com todas as cidades, mais foi um exemplo meio besta pra eu saber se realmente precisa criar um Model (setters, gettes), DAO e Controller para este tipo de situação.

 

Se não, KISS (Keep it simple, stupid). Pra que armazenar num banco de dados uma coisa útil mas tão trivial que um simples array resolve?

E se for algo de 300 registros, vou mesmo ficar inserindo esses dados na mão? Não é algo legal de fazer, e totalmente desnecessário.

[Bruno Augusto 417]

Como eu disse ali no finalzinho, se sua Aplicação precisar de dados, o que é óbvio quando se programando PHP, ASP, Ruby e cia. E estiver programando Orientado a Objetos (faltou essa parte) você vai SEMPRE precisar de um DAO.

 

Quanto a se usar um BD ou não só você pode dizer. Esses 300 registros, por exemplo:

 

- Dos já existentes você vai precisar editá-los com frequência? Suponhamos um catálogo de estabelecimentos comerciais, há a possibilidade de os endereços e/ou nomes das empresas mudarem muito?

 

- Quando você alterar essa lista (se alterar) você o faria em grandes quantidades? Tipo, adicionaria mais do que cem de uma vez?

 

- Se você precisar remover alguma informação, você o faria em grandes quantidades e/ou teria dificuldade em buscar um item em particular?

 

Se você tiver muitas respostas NÃO, considere uma última:

 

- Quando você precisar utilizar essa informação, a filtragem é importante? Ou todos os registros de uma vez são suficientes.

 

Se aqui você tiver um SIM, você vai ter de recorrer à um banco de dados porque simular um WHERE com, por exemplo, PHP sobre arrays, apesar de possível, é complicado.

[Guilherme_90 33]

E estiver programando Orientado a Objetos (faltou essa parte) você vai SEMPRE precisar de um DAO.

Sim, tenho uns modelos prontos, porém estou refazendo meus Gateway tentanto fazer melhor agregação entre os objetos, e tentando implementar nisso um GatewayDataTransfer Pattern.

 

Quanto a se usar um BD ou não só você pode dizer. Esses 300 registros, por exemplo:

 

- Dos já existentes você vai precisar editá-los com frequência? Suponhamos um catálogo de estabelecimentos comerciais, há a possibilidade de os endereços e/ou nomes das empresas mudarem muito?

Não, esses dados acho que a chance de serem editados é de 0.01%, porém eu nunca duvido dessa pequena possibilidade.

 

- Quando você alterar essa lista (se alterar) você o faria em grandes quantidades? Tipo, adicionaria mais do que cem de uma vez?

Bom, pensando na probailidade de haver alterações, se caso isso ocorrece, seria sim no mínimo 100 registros, nosso país é grande! :P

 

- Se você precisar remover alguma informação, você o faria em grandes quantidades e/ou teria dificuldade em buscar um item em particular?

Completando a resposta anterior, seria não, isso SE eu precisar, então já penso na probabilidade 0% desta ação.

 

Se você tiver muitas respostas NÃO, considere uma última:

 

- Quando você precisar utilizar essa informação, a filtragem é importante? Ou todos os registros de uma vez são suficientes.

 

Se aqui você tiver um SIM, você vai ter de recorrer à um banco de dados porque simular um WHERE com, por exemplo, PHP sobre arrays, apesar de possível, é complicado.

Sim, precisei utilizar esta informação, como por exemplo no cadastro e edição de determinado usuário.