Page 1 of 1

Table Data Gatway + Decorator and/or Composition for find

Posted: Fri Jul 14, 2006 2:21 am
by jmut
Hi
Lets asume we have Table Data Gatway built ....with CRUD and everything on a db table.

From ther on we start by findByName() method..... findByDate() method etc.
Now, this starts too look fishy...because if you want to seach by name and date you will build a 3rd method findbByNameAndDate() which is wrong.

So I am thinking of making on Find interface or abstract class. And implement from there


Find_Date implements Find
Find_Name implements Find


and then just build some compose object or something

Code: Select all

$table->find (new Find_Date('2006-03-03'), new Find_Name('Tom')) ;
This gives flexibility because once build, you could search by any combination...just building right objects...... I think this has something with composition/decoration but not quite sure.
Maybe someone more experienced will like to clarify the idea and show the right way to do it :)

Posted: Fri Jul 14, 2006 2:32 am
by Christopher
I think it looks like a great idea. I like the idea of building SQL from objects. There is a Builder pattern that might be worth looking into. Otherwise maybe the Command or Strategy patterns might be closer than Compositie or Decorator.

Posted: Fri Jul 14, 2006 10:10 am
by Ambush Commander
On SQL from objects:

I think this has already been done, but if it hasn't, sounds pretty interesting. It would also solve SQL incompatibility problems.

You'd want to, however, make sure you didn't implement the entire SQL spec, otherwise you might as well use raw SQL (which is, in a way, a programming language, and well defined).

However, I think what jmut's trying to do is slightly different, even if they would have the same implementations. Here are my thoughts:

findByNameDate() probably is a special case behavior, if it is, there's nothing wrong with adding another method. Note that when you've got to many WHERE's, performance suffers negatively, even with indexes (you'd need multi-column indexes).

I think the paradigm you're looking for is a slice of the table, that is, you want there to be different ways of viewing the same set of data. findByDate() could return an arbitrary amount of rows, so you'd probably want limiting and pagination. You'd end up creating a sort of "view" object (bad naming) that would take:

* Descending or Ascending
* Sort by
* Limiters

And construct SQL based on that.