duda: objetos de negocio y conexión a la base de datos

[miktrv]

Hola buenas de nuevo,

Quisiera saber cual es la mejor manera de implementar la conexión en nuestros objetos de negocio.. por ejemplo, el objeto Noticia..

que haría? un __construct($conId), o __construct(Config $config)?

Y después.. cada vez que lo creo.. tendría que pasar el parámetro... no me gusta nada de nada..

Un saludo y gracias!

[GatorV]

Lee sobre Dependency Injection, sirve precisamente para lo que quieres hacer.

Saludos.

[miktrv]

Muchas gracias!

Una duda... respecto a lo de añadir un fichero .ini para los datos de la conexión a la base de datos... es seguro? ( ya se que el fichero se colocaría fuera de la ruta pública.. pero como nunca lo he usado.. )

Un saludo!

[Carxl]

Una pregunta GatorV... pero el hacerlo de esa manera no vuelve dependiente al objeto noticia del objeto conexión?

Porque se debe hacer un require/include para que lo reconozca no? Osea si no existe el objeto conexión que debería pasar con el objeto noticia?

Gracias :)

[_ssx]

Supongo que debería tirarte una excepción de falta de componente conexión...

Es como un carro, necesita llantas para caminar si no las trae seguro no funcionara tu vehiculo

:D Bueno por algo se llama Inyección de "DEPENDENCIAS".

[Carxl]

_ssx, cómo vas?

Pero según tengo entendido, uno podría hacer para evitar esa dependencia, crear otra clase que instancie las otras dos (conexión y noticia) y que sea esa nueva clase la que haga uso de las dos, sin ninguna dependencia entre ellas.

Eso que digo es a manera de diseño, no sé que tan acertado esté.

Gracias!

[GatorV]

Claro para eso es precisamente Dependendy Injection, mira este ejemplo:

Código PHP:

class Noticias {
    private $_db;
    
    public function __construct() {}
    
    public function setDb(DBInterface $db) {
        $this->_db = $db;
    }
}
 

Luego desde donde unes las clases:

Código PHP:

$Db = new DB(/** Datos **/);
$Noticias = new Noticias();
$Noticias->setDb($Db);
 

Así como dice _ssx la clase noticias requiere de una db para trabajar, pero a la hora de usar una interfaz/clase estamos desacoplando que tipo de db va a usar.

En el ejemplo del auto / llantas, usando DI es decirle este auto puede usar cualquier tipo de llanta (necesita llantas para caminar) pero puede ser llantas para nieve, llantas de carreras, etc.

Saludos.

[Carxl]

Mmmm ya entiendo el concepto.

Una pregunta más, en ese caso, que la clase noticias necesitará la clase Db, es mejor usar interface o class? Cuál serían sus diferencias?

Gracias!

[_ssx]

Una interface debido a que puedes cambiar de motor de persistencia en el momento que desees, ya sea una DB o un XML o un Archivo, etc etc...

Al final del dia vas a utilizar una clase, sin embargo la interface se convierte en el "contrato" que debe de cumplir la clase conexión para poder funcionar.

[Carxl]

Perfecto! gracias a los dos por los datos :D

[miktrv]

Iniciado por _ssx

Una interface debido a que puedes cambiar de motor de persistencia en el momento que desees, ya sea una DB o un XML o un Archivo, etc etc...

Al final del dia vas a utilizar una clase, sin embargo la interface se convierte en el "contrato" que debe de cumplir la clase conexión para poder funcionar.

Yo me he perdido en este punto... en que momento se necesita una interfaz??

Un saludo!

[_ssx]

Iniciado por miktrv

Yo me he perdido en este punto... en que momento se necesita una interfaz??

Un saludo!

En el momento que quieres separar tu motor de persistencia para tener Flexibilidad

Código PHP:

  interface Persistencia
{
    public function conectar();
    public function desconectar();
    public function ejecutar(SQL $sql);
}

class SQLServer implements Persistencia{

}

class ORACLE implements Persistencia{

}

class MySQL implements Persistencia{

}

class Noticia{
        private $_db;
        public function setDb(Persistencia $db){
        $this->_db = $db;
        }
        public function getNota(){
        $this->_db->ejecutar('SELECT BLA BLA BLA');
        }
} 
   

Entonces ya tu noticia puedes enviarle cualquier tipo de "persistencia". por que estas usando una interfaz "comun" debido a que todas las clases que implementan Persistencia tendrán los mismos metodos.

Código PHP:

  $nota = new Noticia();
$nota->setDb(new Oracle());
$nota->getNota(); 
   

Código PHP:

  $nota = new Noticia();
$nota->setDb(new Mysql());
$nota->getNota(); 
   

Código PHP:

  $nota = new Noticia();
$nota->setDb(new SQLServer());
$nota->getNota(); 
   

Si observas getNota de la noticia, NO necesita saber con que base de datos esta tratando ;) eso lo hace el lenguaje automaticamente con polimorfismo indirecto.

[miktrv]

Iniciado por _ssx

En el momento que quieres separar tu motor de persistencia para tener Flexibilidad

Código PHP:

  interface Persistencia
{
    public function conectar();
    public function desconectar();
    public function ejecutar(SQL $sql);
}
 
class SQLServer implements Persistencia{
 
}
 
class ORACLE implements Persistencia{
 
}
 
class MySQL implements Persistencia{
 
}
 
class Noticia{
        private $_db;
        public function setDb(Persistencia $db){
        $this->_db = $db;
        }
        public function getNota(){
        $this->_db->ejecutar('SELECT BLA BLA BLA');
        }
} 
   

Entonces ya tu noticia puedes enviarle cualquier tipo de "persistencia". por que estas usando una interfaz "comun" debido a que todas las clases que implementan Persistencia tendrán los mismos metodos.

Código PHP:

  $nota = new Noticia();
$nota->setDb(new Oracle());
$nota->getNota(); 
   

Código PHP:

  $nota = new Noticia();
$nota->setDb(new Mysql());
$nota->getNota(); 
   

Código PHP:

  $nota = new Noticia();
$nota->setDb(new SQLServer());
$nota->getNota(); 
   

Si observas getNota de la noticia, NO necesita saber con que base de datos esta tratando ;) eso lo hace el lenguaje automaticamente con polimorfismo indirecto.

Perfecto,

Sabía para que se usa la interfaz, como un contrato y para asegurarnos de que cumple unos requisitos.. pero no la he implementado en mi clase que trabaja con la base de datos.. jeje ahora ya lo se.. mi idea era usar la clase con el mismo nombre y con funcionamiento distinto, de esa manera sólo tendría que cambiar el código de la clase.. aunque con el uso de la interfaz también puedo.

Un saludo!!

[masterpuppet]

Que bueno se puso el thread, lastima que llego tarde, igual voy a tratar de complementar algo, tomando de base el ejemplo de _ssx(excelentes tus intervenciones ,) y lo que comenta GatorV(Dependency Injection)

DAO's

Código PHP:

interface IDao
{
    public function find($criteria);
    public function findAll($criteria);
    public function save($data);
}
 
class NewsDbDao implements IDao
{...}
 
class NewsXMLDao implements IDao
{...}
 
class NewsWSDao implements IDao
{...}
 
class News
{
    ...
    public function __construct(IDao $dao)
    {...}
    ...
}
 

El injector/assembler a través de una de sus formas mas típicas, un container(muy básico), garantizando las dependencias.

Código PHP:

class Container
{
    protected $_params = array();
    protected static $_shared = array();
 
    public function __construct(array $params)
    {
        $this->_params = $params
    }
 
    public function getNewWithDbDao()
    {
        $pdo = new PDO($this->_params['news.dbdao.dsn']);
        $dao = new NewsDbDao($pdo);
        return new News($dao);
    }
 
    public function getNewWithXMLDao()
    {
        $file = new SPLFileinfo($this->_params['news.xmldao.filename']);
        $dao  = new NewsXMLDao($file);
        return new News($dao);
    }
 
    public function getNewWithWSDao()
    {
        $dao = new NewsWBDao($this->_params['news.wbdao.endpoint']);
        return new News($dao);
    }
 
}
 

y el modo de empleo seria:

Código PHP:

$params = array(/***/);
$container = new Container($params);
 
$dbNew  = $container->getNewWithDbDao();
$dbNew->find($criteria);
 
$xmlNew = $container->getNewWithXMLDao();
$xmlNew->findAll($criteria);
 
$wsNew  = $container->getNewWithWSDao();
$wsNew->save($data);
 

Nota: el ejemplo de _ssx no solo muestra el beneficio de las interfaces, es un claro ejemplo de porque hay que utilizar PDO.

Saludos

[GatorV]

Muy buenos los comentarios, y muestran exactamente los beneficios/poder de usar POO, que no es solo usar clases, si no el poliformismo.

[abimaelrc]

Interesante tema

Una sola cosa, ¿en la clase News hay que también crear los métodos find, findAll y save?

[masterpuppet]

Iniciado por abimaelrc

Interesante tema

Una sola cosa, ¿en la clase News hay que también crear los métodos find, findAll y save?

Si, aunque habría un Layer Supertype y se podría hacer uso de la "magia" para recaer sobre el DAO, con algo de refactoring quedaría así:

Código PHP:

abstract class DomainObject implements ArrayAccess
{
    public function __construct(IDao $dao)
    {/***/}
    
    public function __call($method, $args)
    {/***/}
}
 
class News Extends DomainObject
{}
 

no es mas que un ejemplo y la idea en mi post era mas que nada ejemplificar lo que menciono GatorV(DI), algo muy útil, yo soy partidario de DataMapper + Repository (en fin Doctrine 2).

Saludos.

[miktrv]

Iniciado por masterpuppet

Si, aunque habría un Layer Supertype y se podría hacer uso de la "magia" para recaer sobre el DAO, con algo de refactoring quedaría así:

Código PHP:

abstract class DomainObject implements ArrayAccess
{
    public function __construct(IDao $dao)
    {/***/}
    
    public function __call($method, $args)
    {/***/}
}
 
class News Extends DomainObject
{}
 

no es mas que un ejemplo y la idea en mi post era mas que nada ejemplificar lo que menciono GatorV(DI), algo muy útil, yo soy partidario de DataMapper + Repository (en fin Doctrine 2).

Saludos.

Hola buenas,

Me vuelvo a perder...

Estaría bien que las explicaciones fueran un poco más "accesibles" a todos.. jeje

Un saludo!

[Carxl]

Que tema tan chimba!!! Muy muy bueno!!

Saludos.

[juaniquillo]

Iniciado por Carxl

Que tema tan chimba!!! Muy muy bueno!!

Saludos.

Estoy igual que Carxl. Muy buenos ejemplos de poliformismo. Voy a estar siguiendo este tema de cerca. Saludos.

[masterpuppet]

Iniciado por miktrv

Hola buenas,

Me vuelvo a perder...

Estaría bien que las explicaciones fueran un poco más "accesibles" a todos.. jeje

Un saludo!

Las disculpas del caso miktrv, que parte no te ha quedado clara ?.

Nota: hay hambre de OOP & Patterns , buen síntoma.

[miktrv]

Hola buenas,

Gracias.

Pues lo de los data objects..

Un saludo!

[masterpuppet]

Ahora el que no te sigue soy yo miktrv , esta parte es la que no te queda clara ?

...se podría hacer uso de la "magia" para recaer sobre el DAO...