Table Data Gatway + Decorator and/or Composition for find

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Table Data Gatway + Decorator and/or Composition for find

Post 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 :)
Last edited by jmut on Fri Jul 14, 2006 2:41 am, edited 1 time in total.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
Post Reply