Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Bom dia amigos!
Optei em postar o código antes e deixar a dúvida no final. Lembrando que isso é apenas um caso de estudo.
<?php
interface ICrud
{
public function inserir();
public function alterar();
public function excluir();
//public function listar();
}
?>class Cliente
{
private $id;
private $nome;
private $email;
public function __construct()
{
}
public function setId($id)
{
$this->id = $id;
}
public function getId()
{
return $this->id;
}
public function setNome($nome)
{
$this->nome = $nome;
}
public function getNome()
{
return $this->nome;
}
public function setEmail($email)
{
$this->email = $email;
}
public function geEmail()
{
return $this->email;
}
}
?>
<?phpclass ClienteDao implements ICrud
{
private $cliente;
public function __construct(Cliente $cliente)
{
$this->cliente = $cliente;
}
public function inserir()
{
$this->cliente->setId(1);
$this->cliente->setNome("Jeferson");
$this->cliente->setEmail("jrs@jrs.com.br");
}
public function excluir()
{
}
public function alterar()
{
}
}
?>Ao meu ver, minha classe ClienteDao ainda se encontra muito "acoplada" a classe cliente. Nesse ponto é que ainda não saquei como deveria fazer para "retirar" esse acoplamento tornando-a mais abstrata.
O problema que eu vejo dessa implementação, é que minha classe cliente pode fazer uso de outras classes, e passar vários objetos para dentro da classe ClienteDao ou diretamente para a classe Cliente ao meu ver não seria a melhor maneira de resolver essa questão.
O que os amigos me sugerem?
Ao meu ver, minha classe ClienteDao ainda se encontra muito "acoplada" a classe cliente. Nesse ponto é que ainda não saquei como deveria fazer para "retirar" esse acoplamento tornando-a mais abstrata.
Não pense que sua classe ClienteDAO esta muito acoplada, pois a necessidade de existência dela é ser acesso aos dados do objeto cliente. Por isso você a nomeou DAO (Data Access Object).
O problema que eu vejo dessa implementação, é que minha classe cliente pode fazer uso de outras classes, e passar vários objetos para dentro da classe ClienteDao ou diretamente para a classe Cliente ao meu ver não seria a melhor maneira de resolver essa questão.
Sim, ela pode e deve. Como por exemplo, o contato do cliente ser um objeto e sua relação ser de composição.
É de responsabilidade da classe ClienteDAO saber que cliente possui um objeto do tipo Contato, mas as operações CRUD não são de responsabilidade de ClienteDAO e sim, de uma fictícia e futura classe, ContatoDAO.
Agora, a forma que você vai criar as responsabilidades entre as classes CRUD, depende da sua modelagem.
Exemplo 1 (Deixa a responsabilidade para a Model, ela tem conhecimento das separações)
Exemplo 2 (Deixa a responsabilidade para o DAO, desacoplando a model)
O exemplo 2, ao meu ver, é o correto. A ideia dos exemplos foi para mostrar a relação de transactions.
Outro detalhe. No momento, para a assinatura da interface ICrud, a implementação da classe ClienteDAO atende suas necessidades, mas no momento em que você for implementar o método listar, descobrirá que a classe ClienteDAO necessita de uma instância de Cliente que não será utilizada para o método listar.
Existem alguns outros padrões que você pode utilizar para separar as responsabilidades entre as camadas de negócio, entidade e crud. Como por exemplo TableDataGateway e TableRowGateway ou DataMapper.
Cada padrão possui suas vantagens e desvantagens, mas atendem bem sua necessidade.
A Classe ClienteDao teria mais a responsabilidade de incluir no banco de dados (montar o SQL), então o Cliente poderia ser alimentado pelo sua aplicação conforme a regra de negocio...
E se for o caso como o Doctrine ter um relacionamento o Cliente usaria de outras classes para mapear esses objetos.