MVC e OOP

[Void : 0]

Da-lhe !

 

Salve galera, fiquei um tempo sem postar, muito trampo, muitas dores de cabeça, mas agora estou de volta !

 

ps inicial: *****, ta **** o forum, nao consigo logar ***!

 

Seguinte, conversando com um cara da minha equipe de programação, pergutamos se seria possível mesclarmos os meus object values ou seja os Beans no Java com algum frameworks que siga o pattern MVC (mais especificamente o Zend frameworks 0.8.0)

 

Um exemplo de um object value seria:

class Usuario {private $nome;private $id;public function __construct($id,$nome) {$this->nome = nome;$this->id = id;}public function setId($id) {$this->id = $id;}public function setNome($nome) {$this->nome = nome;}public function getId(){return $id;}public function getNome () {return $nome;} }

Porque, se fomos seguir a estrutura de pastas e arquivos proposta pelo pattern mvc, o resultado seria:

 

/models

/views

/controllers

 

Dentro da pasta controllers, eu tenho os controles, os objetos de negócio.

Dentro da pasta model eu tenho as classes responsaveis por mapear a tabela do banco, com a entidade.

Dentro da pasta views eu tenho a interface com o usuário, o resultado final.

 

Agora, em um sistema, por exemplo, de um forum, temos a classe "Topic" com os devidos setters e getters, aonde eu colocoria essa classe a fim de mesclar com o meu sistema?

Criaria uma nova pasta, ficando:

 

/models

/views

/controllers

/class

 

 

ou, adicionaria na pasta model por exemplo, ficando:

/models

/ObjectValues

/views

/controllers

 

Valeu feras

[Prog 183]

Sua classe se setters e gettes provavelmente não tem nada de HTML, certo? Excluimos a camada de visão.

Provavelmente esta também não será responsável por conectar a camada de visão a camada de modelo, certo? Excluimos a camada de controle.

Provavelmente sua classe de setters e getters vai estar na model.

 

Já trabalhou com Smarty? Implemente uma solução pequena... você vai logo perceber que, o que não é da camada de visão e controle, estará na camada de modelo.

 

Mas nada impede que você crie novas camadas.

[Void : 0]

Boa resposta companheiro!

http://forum.imasters.com.br/public/style_emoticons/default/joia.gif

[walace 1]

Aqui onde trabalho temos a seguinte estrutura:.controller.+model .class .oracle.viewDentro de class temos os setters e getters e dentro de oracle as instruções sql do oracle. Ficou fácil para o caso de termos de implementar a mesma estrutura para o mysql, por exemplo, basta criar uma pasta mysql dentro do model que irá ler os mesmos setters e getters da pasta class.

[Epyllion 0]

Da minha luta com a programação OOP, tirei duas lições:1 - Não use VO / BO.2 - Não abuse de setters e getters;-> 1 - Use objetos de verdade, objetos são dados + funções. Não há motivo para separar os métodos de suas propriedades. -> 2 - Não crie seu objeto e saia atribuindo setters e getters para todas as propriedades. Vá adicionando esses métodos conforme for precisando, dessa forma, você não fica com métodos desnecessários e inúteis.No modelo que desenvolvo atualmente, uso uma estrutura baseada no MVC, porém não estou usando nenhum framework. * Camada de visão : vocês já conhecem. - rss - * Camada de controle : como no MVC, faz a ligação entre o "Model" e a "Visão".* Camada "Model" : Não sei se posso chamar essa camada de Model porque ela é composta por outras camadas. Aqui dentro ficam as regras de negócio, bibliotecas e a camada de Persistência. A camada de Persistência é responsável por cuidar da relação (regras de negócio X banco de dados), ou seja, ela acessa o banco de dados, encapsula os DAOs, etc. Está certo ? Não sei. Funciona ? Funciona.Bom essa é minha humilde opinião. Aparentemente os mestres Prog (ele que me ajudou nos primeiros passos com OOP) e Walace pensam diferente.Esse tipo de tópico é interessante e sempre rende boas discussões.Tenha um bom dia.

[Void : 0]

Fala fera!

 

Então, com relação a esse conceito de usar setters e getters somente quando necessário, disso ae eu ja sabia. Li um artigo na internet muito bom sobre isso, porem perdi o link !

 

Sobre o padrão que voce implementou, não segue as caracteristicas do pattern MVC.

Porque no mvc, a camada de controle é quem cuida das regras de negócio e não o model, entao, sabendo disso oque eu organizei meus arquivos da seguinte forma no final:

 

/controller

../BusinessObjects

/model

../ObjectValues

/views

 

E porque nao utilizar VO, e BO ? São objetos com finalidades totalmente diferentes um do outro ...

[Epyllion 0]

VO / BO

 

Acho que nós estamos falando de coisas diferentes. O que seriam esses "ObjectValues" no teu código ? Os objetos mapeados com o banco de dados ? Fiquei confuso nessa parte.

 

Onde os seus objetos são salvos / recuperados ?

 

O conceito de VO / BO que citei foi o seguinte:

# objeto Carro

 

VO

 

class CarroVO {      private $cor;   private $modelo;         public function __construct($modelo, $cor) {	   $this->cor = $cor;	   $this->modelo = $modelo;   }       public function GetCor() {	   return $this->cor;   }      public function GetModelo() {	   return $this->modelo;   }   }

BO

class CarroBO {			public function Businar() {		echo 'Como é que eu represento o som de uma buzina ?';	}		public function Ligar() {		echo 'Carro ligado';	}		public function TrocarMarcha($marcha) {		echo 'Marcha do carro agora: ' . $marcha;	}}

Entendeu ? Estamos separando as propriedades do objeto do seu comportamento ...

 

Sobre o meu "MVC"

 

Então eu não estou usando MVC. http://forum.imasters.com.br/public/style_emoticons/default/grin.gif

[Fabyo 66]

http://fragmental.com.br/wiki/index.php?ti...tando_VOs_e_BOs

http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas

[Epyllion 0]

Fabyo, obrigado pelos links. Foi depois desses artigos que minha visão sobre OO começou a mudar.

Aconselho o pessoal ler os artigos do blog do Philip também:

http://www.fragmental.com.br/blog/

Setters e Getters:

http://blog.caelum.com.br/2006/09/14/nao-a...ters-e-setters/

[Fabyo 66]

Sobre getters e setters eu usava muito no VB6 num sistema tipo cnab EDI com classe meio que gambiarra mas no dotnet ficou bem melhor, mas no php tenho essa visão só uso quando for muito necessario

 

eu costumo fazer uma classe só com os metodos que eu preciso usar, ja vi classes com uma infinidade de metodos, dai vem a pergunta será que vai usar tudo isso?, claro se for para publicar num forum é mais aceitavel ja que inumeras pessoas iram usar sua classe, e eu costumo a pensar de 2 maneira se eu to desenvolvendo pra mim mesmo é uma coisa se for pra distribuição é outra

[Void : 0]

Entao galerinha!Desculpa, devido as adversidades e prioridades acabei deixando de interagir com este tópico.Seguinte, vai minha opnião agora okEu acho extremamente importante, trabalhar da forma anemica, como trata o primeiro artigo do link do fragmental.Porque, no final, tem-se um projeto bem organizado de facil administração e manutenção.Pra mim é interessante manter meus values objects separados dos meus business Objects.Porque deve haver essa distinção, a grosso modo falando, um objeto é para a persistencia de dados e o outro é para a lógica de negócios .... se eu misturar os dois, o resultado final não sera o esperado, tenho certeza!Bom, mas é o meu modo de programar ... é dificil ter uma convenção, um padrão de desenvolvimento de projetos grandes! Eu estou usando o frameworks da zend, e ele mudou bastante, agora tem suporte a um sistema modular. Ta ficando mais robusto do que ja era, to gostando !Abrasss

[Void : 0]

desculpa a nova postagem, mas tive uma ideia, e gostaria de dividi-la com voceis que se interessaram pelo topico.

 

Bom, como eu havia informado anteriormente, estou usando BO e VO.

Para resolver o problema de um construtor gigante, e varios getters e setters na classe VO eu fiz o seguinte:

 

class TesteVO{ public function __construct($data=array()) {  // Percorro todo o array  foreach($data as $key => $value) {  // E defino novos atributos   $this->$key = $value;  } } public function __get($prop)  {  return $this->$prop; } public function __set($prop, $value) {  $this->$prop = $value; } public function __toString() { }  public function toArray() { }}$teste = new Teste (array("prop"=>123));print $teste->__get("prop");

Virao? dessa forma eu nao tenho um construtor gigante para meu PHPBeans uhuehuehhue

Mas sera que eh viavel ?

Oque voceis acharam da ideia?

Eu acho que supri o uso de varios setters e getters;

 

Comecei a usar aqui, e eu fiz o seguinte, tornei essa classe abstrata e outras classes herdam estes metodos dessa classe, dessa forma se eu tiver alguma coisa especifica dentro das outras classes eu nao fico engessado!

 

abrasss

[Void : 0]

bom, pelo visto ngm gostou da ideia.Pensando de outra forma, se eu tenho um array, nao tem porque eu tornar esse array em um objeto VO dessa forma, sera código repitido, somente se eu tiver alguma outro método dentro do meu VO ai sim, a idéia é viavel!Aguardo opniões

[Epyllion 0]

Porque deve haver essa distinção, a grosso modo falando, um objeto é para a persistencia de dados e o outro é para a lógica de negócios .... se eu misturar os dois, o resultado final não sera o esperado, tenho certeza!

Se o seu objeto serve para persistir os dados ele não é um VO. Ele será um DAO, um Data Mapper, um Active Record, ou "algum-nome-de-padrao-que-se-encaixe-no-seu-modelo". Menos um VO. Repare no artigo do Philip: no diagrama UML que representa a movimentação da conta corretente, ele não diz nada sobre Persistência de dados. É óbvio que essa camada será implementada, porém não nos VOs. Persistência de dados não é responsabilidade dos VOs.Entendeu ? Continuo achando que nós estamos confundindo os conceitos.

Para resolver o problema de um construtor gigante, e varios getters e setters na classe VO eu fiz o seguinte:

Construtor gigante ? Não seria melhor dividir esse objeto em outros objetos menores ? O Philip também escreveu um ótimo artigo sobre isso:http://fragmental.com.br/wiki/index.php?title=FantochesSobre o array ser passado para o construtor, particularmente, não gosto da idéia. Sou a favor da passagem de parâmetros para o construtor do objeto, e asssim, garantir que o estado do mesmo seja válido. Desculpe a redundância e os argumentos muito mal colocados, porém estou com pressa. http://forum.imasters.com.br/public/style_emoticons/default/grin.gif Um abraço.

[Void : 0]

Desculpa,

 

Me expressei mal ao dizer que o meu VO seria o objeto de persistencia de dados.

Na realidade, eu entendo VO, como um objeto qualquer, que não possui nenhum método alem dos setters e getters de seus respectivos atributos ...

 

E entendo como BO os meus objetos responsáveis por toda a lógica de negócio, um exemplo prático:

 

Eventualmente, em uma parte da aplicação, tem-se um form cujo o objetivo é o cadastro de novos usuarios.

 

Então, separando em camadas, temos:

 

A view:

CadastrarUsuario.html

O Controle

UsuarioController.php

O Model (persistencia de dados)

UsuarioModel.php

Dentro da view, temos apenas um formulario em html, cujo os elementos (inputs, combobox e etc) são os atributos do usuário (uma espécie de mapeamento da view com o objeto).

 

Assim que o form é submetido, eu instancio uma classe de controle, e envoco o método NovoUsuario.

Esse método NovoUsuário é responsável por instanciar um objeto do tipo UsuarioVO por exemplo, que é aquela classe que contem apenas setters e getters, nada de lógica de negócios dentro dela.

 

Para validar se o Usuario pode ou não ser cadastrado, eu instancio uma classe do tipo UsuarioBO e passo por parametro o UsuarioVO instanciado anteriormente.

 

No processamento deste método, caso os dados sejam válidos para inserção de um novo usuário, eu instancio uma classe UsuarioModel, e envoco o método "insert" da classe Model passando por parametro o UsuarioVO.

 

É dessa forma que eu pretendo organizar minha aplicação ... oque voceis acham, estou usando algum termo incorreto, não é válido a idéia, é muito complexa, dificulta .... ???

 

Att,

Filipe!!

 

 

Ps.:

Caraca, eu apanho pra postar, não consigo me manter logado no forum!!!!!

[Epyllion 0]

É mais ou menos assim que estou trabalhando atualmente ...

 

Na realidade, eu entendo VO, como um objeto qualquer, que não possui nenhum método alem dos setters e getters de seus respectivos atributos ...

 

E entendo como BO os meus objetos responsáveis por toda a lógica de negócio

Exato. Voltamos à questão inicial: Por que não juntar os dois e formar um objeto de verdade ?

 

Esse método NovoUsuário é responsável por instanciar um objeto do tipo UsuarioVO por exemplo, que é aquela classe que contem apenas setters e getters, nada de lógica de negócios dentro dela.

 

Para validar se o Usuario pode ou não ser cadastrado, eu instancio uma classe do tipo UsuarioBO e passo por parametro o UsuarioVO instanciado anteriormente.

Hummmmmmm, esse é o ponto .... E por que as propriedades do Usuario estão separados do comportamento do Usuario ?

 

Acho que finalmente chegamos a um consenso:

* Você defende o uso de VO e BO (agora sim, sabemos que estavámos falando do mesmo conceito rss).

* Eu sou contra o uso de VO e BO.

 

Seria interessante a opinião de outros usuários ...

 

Void, desculpe ter desviado a atenção do seu tópico, afinal você perguntou "é possivel mesclar object values, com o pattern MVC ? de qual forma ?" e não "Hei, alguém aí é contra o uso de VO e BO ? " * rss *

 

Um abraço

[Void : 0]

euheuheheQue isso, tranquilo cara ... como escritor eu sou um bom programador !É dificil explicar alguns conceitos, perguntar de forma correta, por isso gerou essa confusão toda !No blog do fragmental ele utiliza um termo legal para este contextoÉ viável utilizar "classe de dados" e "classe de negócio" na aplicação ?É viável fazer esta distinção ?Bom, parafraseando o meu velho amigo epylion, conto com a opnião da galera, pois este tipo de discussão é interessante, gera boas idéias ...Eu defendo o uso de Bo e Vo simplismente pelo fator organização.Mas estou quase mudando meu pensamento, e unificando as classes .. porem estou buscando mais referencias!Abrasss

[Void : 0]

Da-lhe rapazeada!!

 

Bom, depois da agitada participação da galera nesse topico ... cheguei a uma conclusão em relação ao uso de VO e BO.

 

Caso voce tenha um projeto não muito grande, tenha uma equipe com um numero significativo de programadores, tenha tempo, e queira trabalhar com um alto nível de abstração, fique a vontade para usar seus VOs e BOs!

 

Caso voce tenha um projeto grande, tenha pouco tempo para desenvolvimento, e saiba organizar de forma correta seus arquivos, trate o objeto de forma unica ... da forma que ele é na realidade ... sem abstrair muito, sem distinguir objeto de dados do objeto de negocio.

 

No meu caso, eu estou pensando em implementar a lógica de negocio dentro da minha classe Model.

 

Minha classe model é um objeto Data-Mapper, nada me impede de antes de inserir um novo usuario por exemplo, verificar se os dados foram preenchidos corretamente..

 

Então, no final teriamos apenas os seguintes procedimentos :

 

Usuario submete o formulario;

Instancio uma classe de controle UsuarioController;

Envoco o método NovoUsuario;

O método NovoUsuario instancia uma classe UsuarioModel;

Envoco o método insert da classe UsuarioModel passando por parametro os valores submetidos!

 

Virão, reduzi o processamento, e continuo utilizando o mvc, mas o MVC puro.

Caso alguem pergunte, a Zend não impede o uso de lógica de negócio dentro da classe Model, muito pelo contrario ela até indica para que seja utilizada dessa forma mesmo ... mais em:

 

http://framework.zend.com/manual/en/zend.d...db.table.insert

tópico 9..4.10 Adding Domain Logic