Models no ZF

[Lucio KrioK 0]

Eu li o livro do Flávio Lisboa e só vi um tipo de referencia sobre utilizacao dos Models, onde dentro de cada model ele carrega so o nome da tabela do banco

 

gostaria de saber o q mais pode ser utilizando dentro do Model, eu vi os relacionamentos , achei muito fera.

 

Li também sobre validacoes e filtros no livro do Flávio (cap 11), mas ele cria arquivos separados (os filtros: filter1.php, filter2.php, etc) em uma nova pasta da aplicacao (Filer). Queria saber se nao tem como essas validacoes e filtros ficarem ou serem usadas nos Models como no rails, acho muito melhor de entender e dar manutençao, por exemplo:

 

No Rails
//verifica qtos caracteres tem o campo username, sendo no minimo 6 e no max 20
validates_length_of  :username, :within => 6..20, :too_short => '<b>User Name</b> must have between 6 and 20 characteres', :too_long => '<b>User Name</b> must have between 6 and 20 characteres'

//verifica se username ja existe no banco
validates_uniqueness_of :username, :message => 'The informed <b>User Name</b> is already registered'

//valida email e se existe (lógico ^^)
validates_format_of :email, :with => /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i, :message => 'Please, type a valid <b>Email</b>'

//verifica se o cara selecionou o sexo dele
validates_presence_of :gender, :message => 'Please, select your <b>Gender</b>'

 

vlw

[diegoholiveira 3]

então, eu me fiz a mesma pergunta esses dias.

 

O negocio é que você pode e na minha opinião deve, inserir toda a logica do negocio dentro dos models, como inserção de registros, validação, filtros, formularios (Zend_Form), relacionamentos e outras coisas, isso é chamado de fat models (modelos gordos).

 

Veja este capitulo sobre isso: http://www.survivethedeepend.com/zendframe...n/1.0/the.model

[Lucio KrioK 0]

Com certeza modelos gordos, como td prática MVC q vi falar, deve ser models grandes e controllers pequenos o max possivel

[Fabyo 66]

A ideia do MVC é separaração por camadas e pela logica Models só cuida de conexao transição de dados

é no controller que se deve validar os dados.

e na View só mostrar o resultado.

[diegoholiveira 3]

A ideia do MVC é separaração por camadas e pela logica Models só cuida de conexao transição de dados

é no controller que se deve validar os dados.

e na View só mostrar o resultado.

Olha, eu discordo. Vamos analisar da seguinte forma, dentro do model podemos ter a implementação de um formulario, logo nesta propria implementação você já tem o metodo isValid, que serve pra validar um formulario e os dados de entrada, que você pode reescrever pra se adequar melhor ao seu projeto, ou seja, tudo isso no model.

 

Quando eu vi a ideia 'fat models' na hora eu vi que aquilo era muito melhor do que deixar as validações e filtros nos controllers. Controllers pra mim são pra controlar o fluxo da aplicação, e só.

[Fabyo 66]

Cada um tem um jeito de pensar e faz do jeito que achar melhor

 

nunca vi validar nada na model e não acho certo, pra mim é gambiarra.

 

do seu jeito funciona? sim

é certo? bom talves

 

mas se seguir a risca a regra e padrao MVC isso ta errado

 

do mesmo jeito que eu posso fazer tudo na controller, ou fazer tudo na model ou na view

 

a ideia proposta não é essa.

 

primeiro precisa entender o conceito.

 

como ja falei voce pode fazer do jeito que achar melhor ou mais facil, mas só não ta certo no conceito MVC, mas isso não quer dizer que esteja de tudo errado, o proprio MVC tem n maneiras de ser usado e interpretar mas claro desde que siga a ideia MVC senão ja não é mais MVC.

 

tem muitos programadores que eu percebo só usar Controller e View.

 

não posso falar que estão errados, a unica coisa que faço é fazer do meu jeito que acho mais correto e que sirva para meus projetos.

[Marcio Leandro 0]

dentro do model podemos ter a implementação de um formulario...

Aqui você já quebrou o conceito da model, que deveria representar o modelo de negócio da aplicação.

[Lucio KrioK 0]

entao vcs vao me dizer q o rails nao trabalha com MVC? mas como isso seria possivel se ele trabalha em cima de MVC?

tds as validacoes, filtros e coisas do tipo sao feitas nos models.

 

da 1 olhada num trecho do livro do Flávio Lisboa, Capítulo 7, página 82

 

"[...]O modelo gerencia um ou mais elementos de dados, responde a consultas sobre seu estado e a instruções de mudança de estado.[...]

[...]O modelo é usado para gerenciar informações e notificar os observadores quando essa informação mudar. Ele contém somente dados e funcionalidades que são relacionados por um propósito comum.[...]"

 

Se um modelo gerencia dados ele é quem faz validação, filtro, etc. Ou seja, se você deixa pra fazer isso no controller, msm funcionando, você sai do padrao MVC

[diegoholiveira 3]

dentro do model podemos ter a implementação de um formulario...

Aqui você já quebrou o conceito da model, que deveria representar o modelo de negócio da aplicação.

 

 

Pra mim um formulario é uma regra do negocio. O que eu faço é criar um modelo abstrato do formulario dentro do model usando o Zend_Form, e na view eu mando gerar este formulario, tipo assim:

 

Controller:

$this->view->formCadastro = $modelUsuarios->getForm('cadastro');

View:

echo $this->formCadastro;

E quando o usuario posta:

Controller:

if ($this->_request->isPost()) {
if ($this->view->formCadastro->isValid($_POST)) {
$modelUsuarios->insert( $this->formCadastro->getValues() );
// redireciona para a pagina de sucesso
}
// caso esteja invalido exibe os erros na view
}

 

Você acha que isso quebra o que é MVC???

 

 

Pegando carona no que o fabio disse, é questão de interpretação dos conceitos, pra mim Model quer dizer todo o modelo de negocios, e isso inclui validação, filtros, banco de dados, implementação de formularios e por ai vai. E controller pra mim é onde eu defino o que acontece quando uma requisição é acionada, e a View é o resultado disso tudo.

[Lucas Renan 2]

lah vai a minha opinião..

 

acredito que os formulários não fazem parte da regra de negócio em si.. então não devem estar nos models...

acredito que qto mais separado estiver, mais claro e limpo os códigos vão ficar.

 

de repente podemos pensar em mais do q 3 camadas..

mas aí eu jah não entendo muito.

 

abs

[diegoholiveira 3]

lah vai a minha opinião..

 

acredito que os formulários não fazem parte da regra de negócio em si.. então não devem estar nos models...

acredito que qto mais separado estiver, mais claro e limpo os códigos vão ficar.

 

de repente podemos pensar em mais do q 3 camadas..

mas aí eu jah não entendo muito.

 

abs

 

porque não fazem parte das regras de negocios?

eu não estou definindo no model o formulario em si, estou definindo a ideia do formulario. o formulario em si eu defino na view (no caso eu apenas dou um 'echo' nele).

[Daniel_Ribeiro 1]

Também não acho que a idéia do formulário deva ser colocada dentro da regra de negócio. Até porque na regra de negocio você estará tratando "DADOS", ou seja, você controla tudo o que vem e o que vai do banco. Agora, como essa informação vem para o banco, quem tem que controlar é o Controller.

Atém porque o mesmo model pode der vários formulários atrelados a ele, desta forma fica muito mais separado o conceito de MVC.

[Lucas Renan 2]

porque não fazem parte das regras de negocios?

eu não estou definindo no model o formulario em si, estou definindo a ideia do formulario. o formulario em si eu defino na view (no caso eu apenas dou um 'echo' nele).

geralmente as regras de negócio não são xhtml

[diegoholiveira 3]

porque não fazem parte das regras de negocios?

eu não estou definindo no model o formulario em si, estou definindo a ideia do formulario. o formulario em si eu defino na view (no caso eu apenas dou um 'echo' nele).

geralmente as regras de negócio não são xhtml

 

 

é quem disse que são xhtml??? ou html???

Eu disse que eu defino o formulario usando o Zend Form, que é uma abstração do formulario que ajuda a filtrar os dados, validar os dados e a criar o xhtml ou html, sendo esta ultima opcional, como dito aqui:

"Zend_Form makes use of several Zend Framework components to accomplish its goals, including Zend_Config, Zend_Validate, Zend_Filter, Zend_Loader_PluginLoader, and optionally Zend_View."

Da uma olhada: http://framework.zend.com/manual/en/zend.form.html

 

 

Agora, se meus argumentos não são suficientes vejam os argumentos do Matthew Weier O'Phinney, que é um dos desenvolvedores do core do ZF:

"In most cases, you want your model to perform its own input filtering. The reason is because input filtering is domain logic: it's the set of rules that define what input is valid, and how to normalize that input.

 

However, how does that fit in with forms? Zend Framework has a Zend_Form component, which allows you to specify your validation and filter chains, as well as rules for how to render the form via decorators. The typical pattern is to define a form, and in your controller, pass input to it; if it validates, you then pass the values to the model.

 

What if you were to instead attach the form to the model?

 

Some argue that this violates the concept of "separation of concerns", due to the fact that it mixes rendering logic into the model. I feel this is a pedantic argument. When attached to a form, Zend_Form can be used strictly as an input filter; you would pull the form from the model when you wish to render it, and perform any view-specific actions -- configuring decorators, setting the action and method, etc -- within your view script. Additionally, the various plugins -- validators, filters, decorators -- are not loaded until they are used -- meaning there is little to no overhead from the decorators when you merely use Zend_Form as an input filter.

 

Basically, this approach helps you adhere to the DRY principle (one validation/filter chain), while simultaneously helping you keep a solid separation of business and view logic. Finally, you gain one or more form representations of your model, which helps with rapid application development, as well as providing a solid, semantic tie between the model and the view. "

 

fonte: http://weierophinney.net/matthew/archives/...our-Models.html

 

 

:)

[Daniel_Ribeiro 1]

Na realidade o que foi apresentado pelo Matthew não foi a utilização de Views (ou criação do formulário) dentro do model. E sim um método dentro do model no qual retorna o formulário que é criado por uma classe. (A função aqui desse método no model, é apenas escolher a classe utilizada para criação do form).

Toda a lógica do formulário não está dentro do model, e sim dentro da classe no qual o metodo getForm irá retornar.

Reparem bem isso no trecho do código:

 

public function getForm($type = 'bug')
	{
		$type  = ucfirst($type);
		if (!isset($this->_forms[$type])) {
			$class = 'Spindle_Model_Form_' . $type;
			$this->_forms[$type] = new $class;
		}
		return $this->_forms[$type];
	}

Desta forma é até aceitável, agora a idéia de colocar a lógica do formulário dentro do model, na minha opinião defere totalmente os padrões de MVC.

[diegoholiveira 3]

Em nenhum momento eu disse que iria implementar views dentro do model. Eu disse implementar as regras de negocios de um formulario lá, usando o componente Zend Form.

 

$class = 'Spindle_Model_Form_' . $type;
			$this->_forms[$type] = new $class;

Percebeu aqui que ele agrupou todas as classes dos formularios dentro da camada model. Ou seja, faz parte dos models (apesar de não ser definido dentro da classe que faz conexão com a tabela do banco de dados).

A camada model neste caso é composta por mais de uma classe, alias, por varias, nos meus projetos cada tabela do banco tem pelo menos duas:

 

xxxx_Table, que extende a Zend_Db_Table e xxxxx_Row, que extende a Zend_Db_Table_Row.