Padrão Active Record

[abilhoa 0]

O padrão Active Record deveria unir lógica de negócio com lógica de persistência, certo?. Porém, na maioria dos frameworks (PHP - cake, code igniter, spaghetti, Ruby - rails, Java - JSF), voltados para o padrão MVC, o Active Record (ou model) guarda somente a lógica de banco de dados. Nesses frameworks há a necessidade de criar 2 classes para uma mesma funcionalidade: o Model e o Controller. A minha dúvida é: Pra que isso?

O correto não seria ter uma única classe que gerenciasse todas as tarefas referentas à ela? Afinal, esse é o preceito da orientação a objetos e do padrão Active Record.

 

No exemplo abaixo fica claro como parece besteira ter que declarar uma classe que praticamente não tem função, senão herdar algumas funções de persistência

Class Produto extends Model{}

Class ProdutoController extends Controller{

	function salvarProduto() {

   	.... lógica de validação ....

   	produto = new Produto();
   	produto.salvar();
	}   
}

 

Não seria mais coerente fazer algo do tipo:

Class Produto extends Model{

  public function salvarProduto(){

   	.... lógica de validação ...
   	this.salvar();
  }

}

 

Ou seja, a própria classe trata de todas as atividades referente à sua funcionalidade.

 

Então, estou equivocado ou é por aí mesmo?

[quitZAUMMM 18]

Não prefere que eu mova para uma área de linguagem de programação especifica?

 

Se 'model' fosse uma classe abstrata ai sim você precisaria implementar o método salvar, do contrário n.

 

[]s

[abilhoa 0]

Não prefere que eu mova para uma área de linguagem de programação especifica?

 

Se 'model' fosse uma classe abstrata ai sim você precisaria implementar o método salvar, do contrário n.

 

[]s

 

Pode mover o tópico. Acho que lá vou ter mais retorno mesmo.

 

Mas então, a classe não precisa ser Abstrata, pois aí as subclasses teriam que implementar obrigatóriamente o método salvar() e esse não é o caso;

A minha dúvida, na verdade, é sobre a necessidade de existirem 2 classes nos frameworks atuais, pra tratar uma mesma funcionalidade - Ex: ProdutoController e ProdutoModel.

Não seria mais interessante e correto criar apenas uma classe Produto e tratar toda a funcionalidade nela, como fiz no exemplo acima?

[Eric_Platas 0]

Eu acho que a separaçao das classes em model e controller se justifica, senao nao implementaria o metodo de desenvolvimento MVC, pra isso precisa ter uma separaçao entre o modelo de dados (model) e o controlador de pagina (control).

 

Se eles implementassem o activerecord padrao em que camada ficaria esta classe???

Talvez eles pudessem desenvolver um activerecord em modo standard (sem implementar o MVC).

 

Na verdade analizando bem o framework nao acho que as funcionalidades dele se encaixem bem na definiçao de activerecord, esta mais pra Row Data Gateway.

[abilhoa 0]

Eu entendo a camada de controle apenas como uma interface entre o modelo e a visualização. Acho que essa camada deveria ser o motor do framework: caregar classes, instanciar objetos, chamar métodos, fazer redirecionamento e etc. E não tratar regras de negócio.

Sei lá, fico com a impressão que essa estrutura foge do paradigma orientado a objetos. Nesse paradigma, uma das premissas é que o objeto deve ter toda responsabilidade sob o estado e comportamento que o identificam como uma entidade. Ou seja, o objeto Produto deve possuir, por exemplo, os métodos: salvar(); exlcuir(); calcularEstoque(); calcularLucro(); e por aí vai.

 

Ninguém mais tem uma opinião sobre o assunto?

 

Moderador, você pode mover o tópico, conforme sugeriu?

[quitZAUMMM 18]

Opa, para qual área você qr q eu mova?

PHP? pode ser?

 

[]s

[abilhoa 0]

Pode sim! Muito obrigado.

 

Puxa vida, só tive uma resposta sobre o tema. Será que ninguém parou pra pensar sobre esse assunto?

[William Bruno 1501]

O padrão Active Record deveria unir lógica de negócio com lógica de persistência, certo?.

não é bem assim.

 

 

 

o Active Record (ou model)

ActiveRecord não é o mesmo que Model.

 

 

Nesses frameworks há a necessidade de criar 2 classes para uma mesma funcionalidade: o Model e o Controller.

o ActiveRecord nunca deve substituir o Controller.

 

A minha dúvida é: Pra que isso?

por causa da separação de camadas.

 

 

O correto não seria ter uma única classe que gerenciasse todas as tarefas referentas à ela?

não.

Afinal, esse é o preceito da orientação a objetos e do padrão Active Record.

de jeito nenhum !!!

 

 

No exemplo abaixo fica claro como parece besteira ter que declarar uma classe que praticamente não tem função, senão herdar algumas funções de persistência

porque você não aplicou o ActiveRecord corretamente, mas sim tentou misturar o Model com o Controller.

você deveria fazer um ActiveRecord sem misturar Controller com Model.

 

 

Então, estou equivocado ou é por aí mesmo?

Está equivocado.

[abilhoa 0]

William Bruno,

 

1. Segundo diversas literaturas, o padrão ActiveRecord é o padrão Data Row Gateway com regra de negócio. Como padrão Data Row Gateway é apenas lógica de persistência, temos o Active Record como um padrão que une as lógicas de persistência e de negócio.
   Só para citar alguns autores que atestam isso: Martin Fowler e Pablo Dall'Oglio.
   Mas qual é o seu ponto de vista?
2. Não quis dizer que o Active Record é um Model, mas sim que nesse contexto o AR faz parte dessa camada. Afinal, o AR não é controlador e nem visão, pois não possui métodos que fazem a interface entre a visão e o próprio modelo.
3. Me diz qual a finalidade da classe ProdutoController, por exemplo, em frameworks tipo CakePHP?
    
   - Validar dados? Isso é regra de negócio e deveria estar no model.
   - Calcular os juros de uma transação? Isso é regra de negócio e deveria estar no model.
    
   A camada de controle deveria servir como uma interface entre a visão e o modelo e não uma classe pra tratar regras. Sendo assim, essa camada pode ser transparente. Portanto, ao meu ver esses frameworks misturam as camadas.
4. O que é um objeto na OO? É a representação de uma entidade pela definição de seu estado e comportamento. Isso significa que uma entidade Pessoa terá os métodos Andar(); Dormir(); Comer(); Falar() e não terá o método Latir();
    
   O que esses frameworks fazem é criar uma classe PessoaModel(), sem função alguma (além da persistência) e outra PessoaController, que terá os métodos Andar(); Dormir() e Comer() e Falar(). Ou seja, criam um classe para comandar outra. Não vejo sentido nisso.
5. Não sei onde eu misturei o controller com model? Somente criei um AR exatamente como o padrão estipula: Regra de negócio com lógica de persistência.
   O que seria um AR correto, então?

[João Batista Neto 448]

Segundo diversas literaturas, o padrão ActiveRecord é o padrão Data Row Gateway com regra de negócio. Como padrão Data Row Gateway é apenas lógica de persistência, temos o Active Record como um padrão que une as lógicas de persistência e de negócio.

 

Correto, mas estou com a impressão que você está confundindo tiers com layers.

 

Não quis dizer que o Active Record é um Model, mas sim que nesse contexto o AR faz parte dessa camada. Afinal, o AR não é controlador e nem visão, pois não possui métodos que fazem a interface entre a visão e o próprio modelo.

 

É justamente por isso que estou achando que você está confundindo tiers com layers.

 

MVC => 3 tiers

 

Data Access, para o MVC, é um layer...

 

ActiveRecord (PoEAA por Martin Fowler), descreve um objeto que possui comportamento e características.

 

Dentro do escopo MVC, a tier Model, que lida com lógica de negócios, pode utilizar o comportamento da entidade provido pelo ActiveRecord.

 

Me diz qual a finalidade da classe ProdutoController, por exemplo, em frameworks tipo CakePHP?

 

Não sei dizer no Cake, mas um ProductController, no ambiente web, lida com o protocolo HTTP. Isso significa que um ProductController deve validar uma requisição HTTP e delegar a responsabilidade das regras de negócio à Model adequada.

 

Nunca, uma Model deve lidar com requisições HTTP ou, em um ambiente desktop, com eventos e ações de usuário; A Model lida com dados e com as regras de negócio que envolvem esses dados, por exemplo:

 

1. Um usuário fez uma requisição HTTP, utilizando um método seguro GET.

 

Nesse caso de uso, seu ProductController sabe que nada deve ser gravado, modificado ou apagado, é responsabilidade do controlador delegar a responsabilidade de manipular os dados da requisição à Model, de forma que apenas listagens ou o estado de um determinado recurso seja entregue ao usuário que fez a solicitação.

 

2. Um usuário fez uma requisição HTTP utilizando o método POST (não seguro).

 

Nesse caso de uso, seu ProductController sabe que o usuário está ciente que sua requisição poderá criar, atualizar ou deletar alguma informação.

 

Quem vai delegar a ação do usuário à Model específica é o Controller, não é responsabilidade da Model tomar essa decisão, ela é responsável pela ação de criar, ler, atualizar e deletar e, para isso, pode ou não utilizar ActiveRecord.

 

A camada de controle deveria servir como uma interface entre a visão e o modelo e não uma classe pra tratar regras. Sendo assim, essa camada pode ser transparente. Portanto, ao meu ver esses frameworks misturam as camadas.

 

O que é um objeto na OO? É a representação de uma entidade pela definição de seu estado e comportamento. Isso significa que uma entidade Pessoa terá os métodos Andar(); Dormir(); Comer(); Falar() e não terá o método Latir();

 

Como eu disse, não conheço o CakePHP, mas como eu disse acima, a função do controlador é lidar com as ações de usuário e tomar decisões relacionadas com essas ações.

 

A função do controlador é justamente controlar qual é a camada de negócio que filtrará, manipulará, apagará ou fará qualquer coisa relacionada com os dados, mas antes da Model fazer alguma coisa, ela depende que o Controller delegue essa função a ela.

 

Não sei onde eu misturei o controller com model? Somente criei um AR exatamente como o padrão estipula: Regra de negócio com lógica de persistência.

 

Se sua Model possuir qualquer verificação ou manipulação HTTP, então você misturou as camadas.

[abilhoa 0]

Quem vai delegar a ação do usuário à Model específica é o Controller, não é responsabilidade da Model tomar essa decisão, ela é responsável pela ação de criar, ler, atualizar e deletar e, para isso, pode ou não utilizar ActiveRecord.

 

A função do controlador é justamente controlar qual é a camada de negócio que filtrará, manipulará, apagará ou fará qualquer coisa relacionada com os dados, mas antes da Model fazer alguma coisa, ela depende que o Controller delegue essa função a ela.

Justamente, o controller serve somente para controlar todas as ações do sistema, além de fazer a interface entre a visão e o modelo. Sendo assim, ele pode ser transparente. Ao meu ver essa camada deveria ser o motor do framework e executar as seguintes tarefas:

 

1. Instanciar os Models;
2. Chamar as actions(métodos dos Models)
3. Carregar as Views
4. Fazer o "link" entre Models e Views;
5. E outras tarefas fora do modelo de negócio (como instanciar Components e Helpers).

Tudo isso de maneira automática.

Data Access, para o MVC, é um layer...

o M do MVC é referente à camada de Modelo de Negócio, que engloba as Regras de Negócio e a Persistência de objetos. O Data Acess Object faz parte dessa camada, pois ele é apenas um tradutor entre o modelo relacional do banco e o modelo orientado a objetos.

 

ActiveRecord (PoEAA por Martin Fowler), descreve um objeto que possui comportamento e características.

Exato!!! E onde está o comportamento e o estado na classe ProdutcModel? Metade está na classe ProductController, que já é outra camada;

[João Batista Neto 448]

1. Instanciar os Models;
2. Chamar as actions(métodos dos Models)
3. Carregar as Views
4. Fazer o "link" entre Models e Views;
5. E outras tarefas fora do modelo de negócio (como instanciar Components e Helpers).

 

Exatamente essa a responsabilidade do Controller.

 

O Data Acess Object faz parte dessa camada, pois ele é apenas um tradutor entre o modelo relacional do banco e o modelo orientado a objetos.

 

Sim, por isso que eu disse que Data Access é uma layer e não um tier.

 

Contudo, não cometa o crime de dizer que "ele é apenas um tradutor entre o modelo relacional do banco".

 

Primeiro porque não necessariamente um banco é relacional.

Segundo porque, não necessariamente, sua Data Access precisa acessar um banco de dados, ela pode fazer interface com um webservice que utiliza uma Service Layer para, de fato, acessar um dispositivo de armazenamento qualquer.

 

Um dos grandes pontos da orientação a objetos é a abstração e, ao dizer "modelo relacional" você abriu mão dela.

 

E onde está o comportamento e o estado na classe ProdutcModel? Metade está na classe ProductController, que já é outra camada;

 

O comportamento e estado da ProductModel está apenas na ProductModel.

 

A ProductController, sabendo disso, vai delegar uma requisição qualquer e utilizar esse estado para responder ao usuário.

[abilhoa 0]

Um dos grandes pontos da orientação a objetos é a abstração e, ao dizer "modelo relacional" você abriu mão dela.

Me referi ao papel do layer DAO nos frameworks atuais, que é apenas fazer a ligação entre os bancos de dados relacionais e o modelo orientado a objetos. Os bancos que não são relacionais, são orientados a objetos; logo, não precisam do DAO, pois eles não lidam com dados (Data Acess Objects). A questão de webservices eu desconheço, então vou pela sua experiência. =)

 

O comportamento e estado da ProductModel está apenas na ProductModel. A ProductController, sabendo disso, vai delegar uma requisição qualquer e utilizar esse estado para responder ao usuário.

Não é bem o que acontece. Nos frameworks tipo cakePHP, Spaghetti e CodeIgniter, só o que há no Model é a persistência de objetos. Regras de negócio, tipo validação de dados, cálculo de juros e coisas do tipo, ficam nos controllers.

 

Estou com essas dúvidas, pois eu tenho um framework que eu havia desenvolvido, que segue uma linha um pouco diferente dos frameworks atuais. Vejam um exemplo resumido e me diga o que vocês acham.

 

class Produto extends Model
{
public function salvar()
{
	Controller::loadComponent("Validation");
	if($this->validation->validate())
	{
		$this->calculaLucro();
		$this->save();
	}

	Controller::redirect("index");
}

public function listar()
{
	$this->find();
	Controller::loadView("lista");
}
}

Esse exemplo ilustra somente a classe que deveria ser trabalhada para a entidade Produto. O Controller fica encapsulad e transparente.

[João Batista Neto 448]

Os bancos que não são relacionais, são orientados a objetos; logo, não precisam do DAO, pois eles não lidam com dados

 

:mellow:

 

Pesquise um pouco sobre isso. ;)

 

Não é bem o que acontece. Nos frameworks tipo cakePHP, Spaghetti e CodeIgniter, só o que há no Model é a persistência de objetos. Regras de negócio, tipo validação de dados, cálculo de juros e coisas do tipo, ficam nos controllers.

 

Estou com essas dúvidas, pois eu tenho um framework que eu havia desenvolvido, que segue uma linha um pouco diferente dos frameworks atuais. Vejam um exemplo resumido e me diga o que vocês acham.

 

	Controller::loadComponent("Validation");

 

Parei de ler o código quando cheguei nessa linha ai, ou seja, não li o código. :P

 

Mas agora começo a compreender seu problema e, dessa forma, vai ficar mais fácil ajudar e, para tal, vou lhe propor uma brincadeira:

 

Pense em uma historinha, algo simples: "Fulano entra no site para visualizar uma lista de produtos...."

 

Vamos analisar sua história, identificar os participantes e modelar adequadamente segundo os padrões de domínio específico que você cita neste tópico.

[abilhoa 0]

Pense em uma historinha, algo simples: "Fulano entra no site para visualizar uma lista de produtos...."

Vamos analisar sua história, identificar os participantes e modelar adequadamente segundo os padrões de domínio específico que você cita neste tópico.

Você está propondo uma situação para estudo?

Se for o caso, então vamos lá:

 

TAREFAS AUTOMÁTICAS REALIZADAS PELO CONTROLLER

1. O usuário entrará na lista de produtos através da url: http://meusite.com.br/produto/listar/
2. Essa URL chamará o arquivo index.php, que em seguida criará uma instância da classe Controller;
3. A classe Controller irá analisar a URL e irá instanciar o model PRODUTO;
4. Em seguida o controller irá chamar o método LISTAR da classe PRODUTO;

TAREFAS REALIZADAS PELO MODEL

class Produto extends Model
{
public function listar()
{
	$this->produtos = $this->find();
	Controller::loadView("lista");
}
}

 

TAREFAS REALIZADAS PELA VIEW

<? foreach($this->produtos as $produto): ?>
<li><?=$produto->nome?></li>
<? endforeach ?>

 

Pronto! Só isso.

 

Parei de ler o código quando cheguei nessa linha ai, ou seja, não li o código. :P

Achou muito absurdo a chamada estática do método? Se sim, então substitua a linha Controller::loadComponent("validation") por new Validation();

Se você achar ruim a linha Controller::loadView("listar") do meu exemplo, então esqueça ela. Digamos que o controller inclua a view de mesmo nome da action.

[William Bruno 1501]

@abilhoa, vamos esperar a resposta do João, mas acredito que o problema com o teu metodo estatico ali, é que a Model, fez uma chamada para o Controller

 

'isso', que eu disse sobre 'misturar camadas'

[abilhoa 0]

@abilhoa, vamos esperar a resposta do João, mas acredito que o problema com o teu metodo estatico ali, é que a Model, fez uma chamada para o Controller

 

'isso', que eu disse sobre 'misturar camadas'

 

Hummm, é, faz sentido.

Mas ainda assim, acho que chamar um método de outra camada não é misturá-las. Já nos frameworks que citei há essa mistura, uma vez que em diversos casos regras de negócio são tratadas no controller.

[João Batista Neto 448]

Mas ainda assim, acho que chamar um método de outra camada não é misturá-las. Já nos frameworks que citei há essa mistura, uma vez que em diversos casos regras de negócio são tratadas no controller.

 

Vamos esquecer os frameworks, o fato de muitos serem famosos não significa que estão corretos.

 

Acredito que o maior responsável por essa confusão é que muitos resolvem estudar padrões de arquitetura sem conhecer padrões clássicos e muitos resolvem estudar padrões clássicos sem ao menos ter compreensão básica sobre responsabilidades, delegações e associações.

 

E são justamente essas "associações", que acredito ser o maior vilão do nosso MVC, vejam só:

 

 

Essas linhas entre os participantes indicam associações, mas o que são elas ?

 

:seta: Uma empresa possui um funcionário.

 

Se o funcionário deixar de trabalhar nessa empresa, a empresa não vai fechar.

Da mesma forma, se a empresa fechar, o funcionário não vai morrer.

 

Uma associação é uma conexão entre dois participantes, uma forma de comunicação que pode ser uni ou bi direcional.

 

:seta: Um carro possui rodas.

 

Se removermos uma roda do carro, ele não vai explodir.

Se o carro fundir, a roda não vai deixar de existir.

 

Por outro lado, se tirarmos a roda do carro, você vai ter um problema para andar.

 

Esse tipo de associação é chamada de agregação, e indica que nosso carro é composto por rodas, mas que não vai explodir ou simplesmente deixar de existir, se removermos as rodas.

 

:seta: Uma pessoa possui uma cabeça.

 

E se removermos a cabeça da pessoa ?

 

Imaginem um livro, e se removermos um capítulo inteiro do livro ?

 

A composição representa uma associação forte, de forma que um participante depende de outro para existir, se removermos a cabeça, a pessoa morre.

 

E nosso MVC ?

 

 

Vejam que temos as associações diretas:

 

O Controller conversa com a View e com a Model.

A View conversa com a Model.

 

E as setinhas pontilhadas ?

 

Essas associações são chamadas de associações indiretas, a View conversa sim com a Controller, mas indiretamente. O mesmo ocorre em relação a Model e a View.

 

Ok, o que isso significa ?

 

Vejamos,

 

Uma associação direta, entre o Controller e a View e a Model:

 

<?php
class DataModel extends ArrayIterator {
}

 

<?php
class Model {
public function getData() {
	return new DataModel( array( 1 , 2 , 3 ) );
}
}

 

<?php
class View {
public function show( DataModel $model ) {
	echo '<ul>';

	foreach ( $model as $item ) {
		echo '<li>' , $item , '</li>';
	}

	echo '</ul>';
}
}

 

<?php
class Controller {
public function handle() {
	$view = new View();
	$model = new Model();

	$view->show( $model->getData() );
}
}

 

<?php
$controller = new Controller();
$controller->handle();

 

E as associações indiretas ?

 

Bom, de fato, uma View não chega para o Controller e fala: "Executa essa ação"

Da mesma forma, uma Model não fala diretamente para a View: "Sabe aquela informação que você está exibindo, atualiza ai porque alguém excluiu um dado"

 

Mas se não fala, como funciona essas "associações indiretas" ?

 

:seta: :seta: GoF

 

 

Observer :seta: Comportamental

 

Participantes:

Subject

:

Define uma interface para adicionar e remover observadores.

Um Subject conhece todos os seus observadores.

Observer

:

Define uma interface para um observador que será atualizado caso um Subject tenha alguma modificação em seu estado.

 

ConcreteSubject

:

Implementa a interface do Subject.

Possui o estado que interessa ao Observer.

 

ConcreteObserver

:

Implementa a interface do Observer.

Mantém o estado do Subject atualizado.

 

No nosso MVC, vamos implementar tanto o Subject quanto o Observer em um único participante chamado Object:

 

<?php
interface Subject {
public function attach( Observer $observer );
public function notify();
}

 

<?php
interface Observer {
public function update( Subject $subject );
}

 

<?php
class Object implements Observer, Subject {
private $observers = array();

public function attach( Observer $observer ) {
	$this->observers = $observer;
}

public function notify() {
	foreach ( $this->observers as $o ) {
		$o->update( $this );
	}
}

public function update( Subject $subject ) {
}
}

 

<?php
class DataModel extends Object implements IteratorAggregate {
private $modelState;

public function __construct( array $array = array() ) {
	$this->modelState = new ArrayObject( $array );
}

public function add( $item ) {
	$this->modelState->append( $item );
	$this->notify();
}

public function getIterator() {
	return $this->modelState->getIterator();
}
}

 

<?php
class Model extends Object {
private $dataModel;

public function __construct() {
	$this->dataModel = new DataModel( array( 1 , 2 , 3 ) );
	$this->dataModel->attach( $this );
}

public function doSomething() {
	$this->dataModel->add( 123 );
}

public function getData() {
	return $this->dataModel;
}
}

 

<?php
class View extends Object {
private $dataModel;

public function __construct( Model $model ) {
	$this->dataModel = $model->getData();
	$model->attach( $this );
}

public function show( $message = 'Mostrando' ) {
	printf( "%s dados\n\n" , $message );

	foreach ( $this->dataModel as $data ) {
		printf( "\tItem %d\n" , $data );
	}

	echo "-----------------\n\n";
}

public function update( Subject $subject ) {
	$this->dataModel = $subject;
	$this->show( 'Atualizando' );
}
}

 

<?php
class Controller {
private $model;

public function handle() {
	$this->model = new Model();
	$view = new View( $this->model );

	$view->show();
}

public function clickAction() {
	$this->model->doSomething();
}
}

 

Ok, quando a aplicação inicia, o método handle() do Controller monta nossa aplicação:

 

<?php
$controller = new Controller();
$controller->handle();

 

A saída:

 

Mostrando dados

 

Item 1

Item 2

Item 3

-----------------

 

Ai, nosso usuário navegando, clica em um botão que faz alguma coisa:

 

$controller->clickAction();

 

E nossa exibição é atualizada:

 

Atualizando dados

 

Item 1

Item 2

Item 3

Item 123

-----------------

 

Como pode ver, a ação clicar do usuário foi pega pelo Controller que falou para a Model, o usuário que fazer alguma coisa.

 

A Model, como detém a responsabilidade pela regra de negócio da aplicação, faz alguma coisa.

 

Só que essa alguma coisa modifica seu estado e a View precisa ser atualizada.

 

Nesse instante, nosso padrão Observer faz o trabalho dele, notificando a View que o estado da Model mudou e que ela precisa atualizar a exibição do usuário.

 

:seta: Está tudo bem até aqui ?

[Bruno Augusto 417]

João, pergunta de novato:

 

Se eu entendi direito, nesse esquema em que a View fica esperando a Model fazer alguma coisa através do Controller para que uma atualização ocorra, não acaba complicando aquilo que o MVC tenta descomplicar?

 

Eu vejo assim:

 

• O usuário acessa a página e faz uma requisição.
  
• A Aplicação recebe a requisição e o Roteador determina qual Controller a manipulará
  
• O Controller instancia um ValueObject que seria pai da Model, e informa as "opções do usuário", como por exemplo a forma de ordenar os resultados de uma query (ASC/DESC) que pode estar presente na URL.
  
• Então o Controller instancia a DAO que recebe o ValueObject no construtor e com essas informações executa (ou pode executar), por exemplo, insert(), update(), delete()
  
• Cada um desses métodos retorna (pelo menos no meu caso) um ovjeto PDOStatement e, no Controller, atribuo-se à uma variável de template o valor de DAO -> fetchAll()
  
• A View itera sobre esse array (ou objeto stdClass) e exibe as informações.
  

Certo? Errado? Quase isso? Ou nada disso?

[João Batista Neto 448]

não acaba complicando aquilo que o MVC tenta descomplicar?

 

E o que você acha que o MVC tenta descomplicar ?

 

:seta: O único foco do MVC é a camada de exibição.