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 decoupl
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 reall
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
Hi,
I have to admit that I agree with Simon on this one. Don't over-engineer
your application, KISS.
Best,
--
Andries Seutens
http://andries.systray.be
Simon Mundy schreef:
Perhaps I've missed something here, but why are you extending your
classes to the nth degree to achieve this? I can'
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
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
|
Okay I ended up with something like this
Class My_Model
{
private $_gateway;
private $_gatewayClass;
protected function gateway(){
$this->_gateway = ($this->_gateway) ? $this->_gateway : new
$this->_gatewayClass();
return $this->_gateway;
}
public function insert($d
I started following the gateway() approach then read the next posts.
I'm thinking about making a model class and extending my models from that.
The model class will have all the db_table methods like insert, update etc.
My models will then all extend from the model class so that they have all
t
I create my models, and then spit the data to a View Helper called Table
Render
This table render utilises PEAR Structures so I can expose the data in
many different ways, including an HTML table, CSV, XML, Excel, PDF etc.
Just another abstraction layer to help with reporting, it also does
p
I've had a question about this too, though specifically it doesn't
really deal with pulling one "book". I was wondering what solutions
people have for wanting to pull a set of books (to use the earlier
example) from a category (say, biography) and then limit the list (for
paging).
I had guessed t
Interesting and I like Karol Grecki's suggestion about using __call() to
provide $model->insert() as an alternative to $this->_gateway->insert()
With Bill's comments and Sam's approach. I've found myself arriving at this
example. Is it viable? Any comments?
|-- controllers
|-- models
| |-- P
It might be better for the model to abstract those calls.
Maybe you could use __call() and redirect calls like $model->insert() to
$this->_gateway->insert()
Cheers
Karol
Sam Davey wrote:
>
> Now in my controller, in the ever present add, edit and delete actions I
> simply use the following c
The problem with your new setup is that the model is still closely
linked to the table subclass (the gateway).
If you use a data source other than the gateway, you'll have to
rewrite your model interaction, 'cuz the insert() and update() etc.
functions may no longer be available.
Instead, try
I am trying to use Zend_Db_Table_Row + Zend_Db_Table to create the model
layer.
So I can put business logic into the row subclass, for a specific entity:
|class MyRow extends Zend_Db_Table_Row
{
public function isValid(){
if($this->myAttribute...
}
}
|
And in the table class, I can
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
|-
Or this?
|-- controllers
|-- data
| |-- rdb
| | |-- Images.php
| | `-- Users.php
| `-- xml
|-- models
| |-- Image.php
| |-- Images.php
| |-- User.php
| `-- Users.php
`-- views
Mark Maynereid wrote:
>
> Hi,
>
> I like the reasoning and am trying to work with it at the mom
Hi,
I like the reasoning and am trying to work with it at the moment. So how might
these table and model class files best be organised? Should I put the table
classes and the model classes in the same directory or should I try and
separate them out? eg.
|-- controllers
|-- models
| |-- busin
Zend Framework has a deliberate design goal that it requires no
configuration files -- especially not XML configuration files. :-)
The Prado SQL mapper solution you cite uses an XML configuration file to
define the map between object properties and relational attributes in a
database schema.
Ins
Hi Darby,
Thanks, this was the closest response to what I was looking to achieve.
Although the other posts have prompted me to redesign my models because of
the problems/improvements suggested.
I think that the Data Mapper is what I'm looking for... but now I know the
pattern to look at, there
Sam Davey wrote:
Hi,
...
But this really just defers my question and I am no closer to a solution.
Okay, lets assume the above and my models now don't extend Zend_Db_Table.
My Models (Product, Manufacturer, Category) are now business objects and
focus on functionality not data. Do I really
I agree with the other statements that best practices include making
Model classes that are decoupled from database table representations.
The assumption that there's a one-to-one mapping between Models and
Tables is more or less a characteristic of Ruby. We can see many
examples where this ass
Hi Sam,
I think it is fine to have classes that extend Zend_Db_Table_Abstract,
but if you consider these to be your model classes, you are tightly
binding your implementation to the database schema (and to that you are
using a database at all). Maybe this is okay for some applications, but
other a
What I did was extending zend table and storing it inside my models and
abstracting calls to database within the object iself. I did it on small
scale for now, so I'm not sure how will this work out for me in the future.
The idea is to use composition instead of inheritance and if you still need
t
Hi,
That sort of makes sense, perhaps I should be adding database access as a
behaviour via composition rather than as a characteristic which is
inherited.
There is no question that extending Zend_Db_Table has massive advantages.
Before v 1.0, I created my own CRUD code using Zend_Dd, but I've s
Hi Sam,
IMHO model classes should not extend the table. They should reflect business
objects and focus on functionality not data. If they need database access
you can give them reference to a table object. I try to avoid "database
driven development", I decide what functionality I need and the da
I've been having similar challenges in the application I'm working on. So far, I
personally haven't ran across any sort of design pattern or best practice that
really addresses this issue.
I don't know how much this helps, but here's an idea I've been kicking around in
my head. Set up your dir
Hi,
First off thank you to everyone who contributed to getting the first release
out. The emphasis the framework puts on best practices has massively
improved my analysis and development techniques (or should I say its
improved my awareness... the rest will hopefully follow with practice).
Afte
27 matches
Mail list logo
