Técnica De Desenvolvimento Em 5 Camadas

[Paulo_Candango 0]

Pessoal, desenvolvemos aqui um módulo didático de progromação em várias camadas, no caso a aplicação está escrita em PHP, gostaria que havaliassem oque está bom e o que pode ser melhorado. Segue o esquema.

 

Dividimos a aplicação em 5 camadas: visão, controle, modelo, negócio e persistência.

 

 

 

1. na Visão eu chamo o Controle, veja:

 

	$enqController = new EnqueteController(null, null, 1); //Passando o tipo de enquete que eu quero, no caso seria 1
	$tmp = $enqController->consultaEnquete();
	echo $tmp->getTitulo()."<br />";
	
	foreach($tmp->getOpcoes() as $obj){
		echo $obj->getDescricao()."<br />";
	}

 

 

2.3. O Controller recebe, instancia um Model e joga para a camada de Negócio:

 

	class EnqueteController {
		
		public $enqueteModel;
		public $enqueteBO;
		
		public function __construct($id, $titulo, $idTag){
			
			$this->enqueteModel = new EnqueteModel();
			$this->enqueteModel->setId($id);
			$this->enqueteModel->setTitulo($titulo);
			$this->enqueteModel->setIdTag($idTag);

			$this->enqueteBO = new EnqueteBO();
			
		}
		
		public function consultaEnquete() {
			
			$tmpEnquete = new EnqueteModel();
			$tmpOpcoes = new OpcoesController();
			
			$tmpEnquete = $this->enqueteBO->consultaEnquete($this->enqueteModel);
			$tmpEnquete->setOpcoes($tmpOpcoes->consultaOpcoes($tmpEnquete));

			return $tmpEnquete;

		}
		
	}

 

 

4. A camada de negócio recebe, trata as regras de negócio que nesse caso não tem nenhuma e passa para a Persistência:

 

	class EnqueteBO {
		
		private $enqueteDAO;
		
		public function __construct(){
			$this->enqueteDAO = new EnqueteDAO();
		}
		
		public function consultaEnquete($enqueteModel){
			
			return $this->enqueteDAO->consultaEnquete($enqueteModel);

		}
		
	}

 

 

5. Que por fim recebe e faz o trabalho de acessar o banco e etc:

 

	class EnqueteDAO extends GenericDAO {
		
		public function consultaEnquete($enqueteModel){
			
			$sql = "SELECT * FROM tb_enquete WHERE id_enquete = ".$enqueteModel->getIdTag()." LIMIT 1";
			$this->getConexao();
			$resultSet = $this->sql($sql);
			$obj = $this->fetch_object($resultSet);
			
			$tmpEnquete = new EnqueteModel();
			
			$tmpEnquete->setId($obj->id_enquete);
			$tmpEnquete->setTitulo($obj->titulo);
			$tmpEnquete->setIdTag($obj->id_tag);
			$tmpEnquete->setOpcoes($obj->opcoes);
			
			return $tmpEnquete;
			
		}

[Bruno Alano 0]

Desculpe, mas não gostei da técnica... É um simples MVC + "Fru Fru".

 

O padrão MVC é adotado pois ele é: COMPLETO, PRÁTICO, RÁPIDO, FÁCIL, SEM "FRU FRU". (Desculpe ultilizar o Caps, mas é para prestarem atenção).

 

 

Desculpe, mas sou contra sua técnica.

[João Batista Neto 448]

É um simples MVC.

 

De fato @Paulo_Candango, você está confundindo tiers com layers e o que você implementou foi de fato um MVC.

 

O padrão MVC é adotado pois ele é: COMPLETO, PRÁTICO, RÁPIDO, FÁCIL

 

@Bruno Alano,

 

Em alguns tipos de aplicação, o MVC pode ser o melhor modelo de arquitetura porém, se a complexabilidade da aplicação cresce esse modelo passa a ser incompleto e insuficiente.

 

Com apenas 3 camadas fixas, temos um problema se nossas regras de negócio estiverem distribuídas em vários pontos ou se você precisar adicionar recursos dinamicamente à aplicação.

 

Quando se trabalha com N-tiers você passa a ter a possibilidade de se adicionar qualquer coisa em qualquer lugar exatamente quando precisar, sua aplicação passa a ser escalável tanto em software quanto em hardware. Como a PresentationLogic conversa com a BusinessLogic utilizando-se de uma API pública, suas regras podem estar distribuídas entre vários fornecedores ou equipamentos, como as três camadas intermediárias trabalham ao mesmo tempo como clientes e servidores, você possui ainda a possibilidade, através de uma camada intermediaria, encontrar o melhor serviço para tratar uma determinada requisição em um determinado momento eliminando assim uma sobrecarga de um determinado serviço.