iosonogio wrote:
Jack Sleight wrote:
That row object will then have all the behaviour (save, delete etc.)
that you'd expect. See:
http://framework.zend.com/manual/en/zend.db.table.html#zend.db.table.find
http://framework.zend.com/manual/en/zend.db.table.row.html
For more info.
Hi,
right but I just would not like to use Zend_Db_Table gateway since it
requires my business object (Article) to extend Zend_Db_Table and this is
not very good from an OO perspective.
I would create a
class My_Db_Table_Article
extends Zend_Db_Table
{
...
}
...which would be just the access layer to the article storage.
Then I would create a
class Article extends whateverYouWant implements whateverItShould
{
/**
* @var Zend_Db_Table
*/
private $_storage;
[...]
}
Then you have your model doing just Business Logic, and it doesn't
have to care about database logic.
It is commonly misunderstood by PHP developers, that the model is the
database-mapping object itself. If you have your database accessor as
a private property (posibly set with a Strategy or Factory template)
then your model could be independent of your DB layer. You could even
make all your db-layer classes implement an interface, eg
dataStoreInterface, and all Models would include dataStoreInterface
instead of Zend_Db_Table, and then create
class Xml_Article implements dataStoreInterface {}
which you could inject into Article class instead of
My_Db_Table_Article, so you cold work with xml articles the same way
you work with articles stored in DB.
Article is an Article, and it does not matter whether it comes from
database or any other data source.
Word of explanation:
It's an Idea currently developing in my mind, and not yet proved
architecture. Please think it over yourself. I am going to develop my
new application using this scheme, but it might change by the time I
will start writing. My current applications are a bit old and they do
not use any db-mapper, just plain sql.
--
Regards,
Szymon Wilkołazki
