Hi Mark,
I've just finished refactoring my design using the feedback from my original
post. I'll describe what I've done which might help you... or others can
stop me in my tracks and tell me I'm going the wrong way about it.
First here is a simplified version of my structure
|-- controllers
|-- models
| |-- Product.php
| |-- Product
| | |-- Gateway.php
| |-- Manufacturer.php
| |-- Manufacturer
| | |-- Gateway.php
| |-- Distributor.php
| |-- Distributor
| | |-- Gateway.php
|-- views
Using the PEAR naming convension and folder structure this illustrates 6
classes Product and Product_Gateway, Manufacturer and Manufacturer_Gateway,
Distributor and Distributor_Gateway.
Basicaly my original models which extended the Zend_Db_Table have now been
turned into Gateways to speak to the specific related table. These look
something like this:
class Product_Gateway extends Zend_Db_Table
{
protected $_name = 'product';
private $_pager = NULL;
public function findByFilter($fValues, $perPage=NULL,
$offset=NULL)
{
// Custom find method which is why Zend_Db_Table was
extended
}
}
So currently my Product model only contains the following code
class Product
{
public function gateway()
{
return new Product_Gateway();
}
}
Now in my controller, in the ever present add, edit and delete actions I
simply use the following code
$this->model = new Product();
$this->model->gateway()->insert($data); // or ->update($data), or
->delete($data)
There is obviously data validation/filtering needed in the controller to
prepare the data. But these two lines deal with the database via the
gateway.
Does this sound like an okay method to others? I realise it could be
abstracted further via the factory method to serve gateway objects, that way
other gateway classes could be created to save to flat files or XML etc.
But thats not really necessary for my application.
In answer to my original question about more complicated things such as data
required from joins etc... after further investigation of Prados rather
complex solution and in light of Bill's respose and Bryce's $0.02... it
looks like anything related to this issue should just be whacked in the
Product model... its looking sparce now anyway.
The reason I'm so interested is because a large proportion of my job
involves creating reports for people based on our data. Loads of reports,
and currently just in individual scripts away from any MVC architectue...
each with their own queries and perhaps queries within queries.
If moving over to MVC it looks like the queries and sub queries for all
these reports should just be shoved in corresponding models? Am I right?
--
View this message in context:
http://www.nabble.com/Models%2C-Objects-and-RDBMS---Best-Practise-tf4052812s16154.html#a11531730
Sent from the Zend Framework mailing list archive at Nabble.com.
