Hi Sam
I agree with Simon that this is over-engineered. I don't buy this factory
idea.
Remember about YAGNI principle. It's not like you gonna switch to xml
storage, will you?
If try to build something super flexible that yo don't really need it will
bite you in the ass sooner or later.
What if you add a model that will not fit the whole gateway pattern, will
you create another factory for it? And if you change the gateway interface,
you potentially break a lot of code because you expose it as a model's
public interface.
Anyway, it looks like model just fetches gateway from the factory and passes
it to the caller. So the only interaction between the model and the gateway
is delegating a call to the factory. Does it make sense?
$this->model = new Product();
$this->model->gateway()->insert($data);
You could do the same without even instantiating a Product by calling a
factory. Would it be any different? Or you could just instantiate the
gateway by removing the factory and it wouldn't change anything in my
opinion.
Cheers
Karol
Sam Davey wrote:
>
> 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#a11575398
Sent from the Zend Framework mailing list archive at Nabble.com.
