Caio,
Fazendo
class Categoria {
public $nome;
public function inserir() {
$query( "..... " $this->nome " .... " );
}
me parece estar adequando seu código ao padrão Arquitetural Table Gateway, correto ?
Caio,
Fazendo
class Categoria {
public $nome;
public function inserir() {
$query( "..... " $this->nome " .... " );
}
me parece estar adequando seu código ao padrão Arquitetural Table Gateway, correto ?
Oi Marcelo, tudo bom?
na verdade, o pattern TableGateway é uma camada que representa a tabela no nosso sistema. No nosso caso, estamos adicionando à entidade categoria o método inserir. Há apenas uma camada, a de modelo, que além de representar uma categoria contem a funcionalidade de inserir uma categoria no banco.
Qualquer problema é só falar =)
Abraço e bons estudos.
oi André!
Pelo diagrama UML que você me passou do site do Martin Fowler, o modelo está numa classe e o table gateway em outra...
Porém, pelo exemplo do professor, ele mistura na mesma classe modelo pois coloca atributos id e nome e métodos de persistência como inserir, alterar etc.
Neste caso dele, como se enquadraria então ?
Exatamente, temos uma classe de modelo para representar uma Categoria. E, dentro dessa classe de modelo temos métodos para gerenciar essa entidade no banco de dados também.
Não acredito que haja um padrão de projeto (design pattern) que se encaixe nesse caso =)
Normalmente, as classes de modelo contém apenas a regra de negocio e criamos outra camada para gerenciar essa entidade no banco de dados. Isso partindo do principio de responsabilidade unica (SRP) que é bastante discutido nos conceitos de SOLID.
Entretanto, um framework bem comum que utiliza uma abordagem parecida é o CodeIgniter nas classes CI_Model a galera normalmente adiciona lógica de banco também.
Abraço!