Hey Sam
No worries - I'm in a particularly good mood after a less hectic week
so some time jousting back and forth on the mailing list makes for a
pleasant way to spend some downtime :)
The only reason I made the point about not over engineering is that
most of the abstraction and decoupling has already been done for you
with the Zend Framework.
There's really not much to be gained from adding lazy loading to your
model or creating a gateway. A Zend_Db_Table is _already_ a gateway to
the Db_Adapter - the table can extend any kind of backend you wish it
to, simply by passing a specific $db object at construction. And if
your object doesn't require any storage or lookup (i.e. it's for
processing, validation, decoration, etc) then it need not extend
Zend_Db_Table at all - you can simply create your own domain-specific
model.
For instance, for 99% of my sites I have a base 'Model_Abstract_Base'
class that provides nothing more than a simple storage object (get/set/
has methods and __get / __set / __isset for convenience). I also have
a Model_Abstract_Db class for models that I know will require storage
and retrieval, and this simply extends Zend_Db_Table_Abstract and
shares the same base methods.
From this I still have a relatively 'shallow' ancestry and a pretty
easy pattern to follow for anyone other than me trying to figure how
to get data in and out of my application logic.
I'm not in favour of 'hiding' the code if it's never needed - it can
be a recipe for trouble later on down the track when trying to
identify bugs. I'd rather be explicit with my choice of models and
make it easy to draw a straight line down the food chain. Both from
the point of keeping it simple and also pure laziness :)
Don't think that you can't extend the Zend_Db_Table and
Zend_Db_Table_Row objects though - this is what they're specifically
designed for. There's hooks for updates, saves, deletions,
constructors, etc. so you can perform domain-specific behaviours for
your models.
Is there specific behaviours that you're trying to achieve with your
application? It may help to address them more specifically than the
implementation, because out of that you may find that there's much
easier and less complicated ways to express these needs.
Hope this helps(?)
Cheerio
Hi Simon,
Thanks for the feedback... please don't view this as a rebuttal, I
requested
feedback because I am unsure it was the correct way to do things.
Here are
some discussion points about what I was trying to achieve and why.
The application I am currently working on is only simple and really
its only
for my own needs with the aim of getting familiar with the framework
and to
practise/implement a number of things I have recently learned about
OO and
design patterns etc.
My last response was aimed at having a go at Jurriën Stutterheim
suggesting
of abstaction and decoupling. After all I thought that decoupling
and code
reuse was the main aim of OO.
Why am I trying to do this?... well I have a very large system I am
responsible for. I did not develop it from scratch and it has not
been
developed with priority put on decoupling etc. Sure it has classes
but they
are acting merely to group related functions rather than anything more
advanced.
So if we were to look at the class responsible for the business
logic of a
product I have a file which is almost 3000 lines long... bloated to
the
extreme. Granted some of this code is behaviour and could be
refactored as
composition... but a lot of the code is simply validation, CRUD, and
getting
related data for various reports about products.
(as far as I can see) The code I have suggested does not extend
classes to
the nth degree. The only class which extends anything is the
Product_Db_Gateway which extends Zend_Db_Table. The
PersistenceGatewayFactory simply serves the gateway object to the
model (is
this not compostion at run time?). The Gateways all implement an
interface
which should not change (thats what interfaces are for) and if a model
doesn't need a gateway (because its not realted to a DB table) then
the
gateway() method is never called.
The end result is that it hides the CRUD code.
If I were to just create the model class and have that extend
Zend_Db_Table
then in the future I would not be able to extend any model. And I
imagine
that may well be useful.
Sure in the interest of YAGNI and KISS if the aim of my application
was a
small website listing products and manufacturers then what you
suggest is
far (FAR) more reasonable.
But what if its much more complicated.
What do you think?
* * * *
I'll be honest though... none of this has really answered my
question about
how to get loads (and loads) of various sets of related data back
from a
relational database without sprinkling masses of SQL code throughout
your
model classes. All of which ensures your classes are heavily coupled
and
massively bloated.
I've think that the Data Mapper pattern is what I need and I will be
looking
at that next.
--
View this message in context:
http://www.nabble.com/Models%2C-Objects-and-RDBMS---Best-Practise-tf4052812s16154.html#a11576255
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
