Perhaps I've missed something here, but why are you extending your
classes to the nth degree to achieve this? I can't see any real reason
for using the gateway factory. It's not as if you'll be using
different Product models with separate backends within the one
application, so why not just have it extend Zend_Db_Table?
If you change to an XML backend, then you can update your class
definition then rather than have a config file determine it. Besides,
isn't there a Zend_Db_Adapter_Xml anyway?
I'd go for simplicity as much as possible - don't try to over-engineer
your solution for the sake of theory if your application doesn't
really benefit from it.
Hi,
Even though my application doesn't need this flexability... I
thought that
in the interest of polymorphism and basically to practise my OO
skills I'll
implement my factory abstraction to see what other people think of the
solution.
My directory stucture is now
|-- controllers
|-- models
| |-- Product.php
| |-- Product
| | | Db
| | | | -- Gateway.php
| |-- Manufacturer.php
| |-- Manufacturer
| | | Db
| | | | -- Gateway.php
| |-- Distributor.php
| |-- Distributor
| | | Db
| | | | -- Gateway.php
|-- views
This gives rise to a renaming of my gateway classes to
Product_Db_Gateway,
Manfacturer_Db_Gateway and Distributor_Db_Gateway.
Now in my config.ini file I simply specify a storage engine
[general]
storage_engine = Db
So I just need a Factory class to server up a persistence gateway
which I
have implemented like this:
class PersistenceGatewayFactory
{
public static function getGateway($type)
{
$registry = Zend_Registry::getInstance();
$config = $registry->get('config');
$config->storage_engine;
$gateway_class = $type."_".$config->storage_engine."_Gateway";
// e.g. gateway_class = Product_Db_Gateway
if(class_exists($gateway_class))
{
return new $gateway_class;
}
else
{
throw new Exception("The gateway class does not exist");
}
}
}
This means that my models now gets its persistence object in the
following
way
class Product
{
public function gateway()
{
try {
$gateway =
PersistenceGatewayFactory::getGateway('Product');
} catch (Exception $e) {
throw $e;
}
return $gateway;
}
}
This means that I can change the storage engine if I need to. So for
example if I suddenly wanted to store everything as Xml then I would
define
Product_Xml_Gateway, Manufacturer_Xml_Gateway,
Distributor_Xml_Gateway.
Provided any of these Gateway classes implement a particular
interface which
includes the insert, update, delete, findByFilter methods then it
should all
work.
$this->model = new Product();
$this->model->gateway()->insert($data);
$this->model->gateway()->update($data);
$this->model->gateway()->delete($data);
I can see how Jurriën's approach would work, this is just my take on
it.
Can people give me some feedback on my approach? I know there are
many ways
to develop OO code... but I always find that 3 months down the line
I work
out a new way to do stuff which should have been obvious in the
begining. Or
there is a problem that I didn't see that someone points out later.
It helps to get feedback from other experienced OO developers,
although my
application is still really simple I've already refactored it a
number of
times mainly because of this post.
Thanks
--
View this message in context:
http://www.nabble.com/Models%2C-Objects-and-RDBMS---Best-Practise-tf4052812s16154.html#a11569435
Sent from the Zend Framework mailing list archive at Nabble.com.
--
Simon Mundy | Director | PEPTOLAB
""" " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654
4124
http://www.peptolab.com
