Page 1 of 1
Design pattern . Table Data Gateway.
Posted: Fri Apr 28, 2006 6:31 am
by jmut
Ok , I have this fancy book by
Martin Fowler "Patterns of Enterprise Application Architecture" and it is damn good stuff.
I have particular question about table data gateway pattern.
I see it represents litterally a certain table for example.
But how do I handle multiple table reference..(joins),
and transactions.
Could someone give me a lead to these multiple table stuff.
Do I build another object to represent the connection between tables(object)?
Would be great to example on making join or something using this table data gateway pattern.
Thank you a lot for spending time.
Cheers,
JD
Posted: Fri Apr 28, 2006 7:46 am
by cj5
What exactly are trying to do? Are you trying to learn how to build complex SQL statements, or are you trying to come up with an efficient way to code, so that you can access data results?
Posted: Fri Apr 28, 2006 8:13 am
by jmut
cj5 wrote:What exactly are trying to do? Are you trying to learn how to build complex SQL statements, or are you trying to come up with an efficient way to code, so that you can access data results?
I don't know how to simplify this more.
You have table1 (class table1) and table2 (class table2).
How do you join them so you get data from both tables. (as in sql joins.).
How is the correct way to program this using Table Data Gateway.
Posted: Fri Apr 28, 2006 11:54 am
by Christopher
Table Data Gateway is a name for us to use to describe an object that provide finders and insert/update/delete methods for a single table. Just like Dalmatian is a name for a specific kind of dog -- Table Data Gateway is a specific kind of Gateway. If you think the finders + insert/update/delete interface makes sense for you then there is no reason why you can't have joins for the finders and do multiple insert/update/delete operations inside those methods. The Gateway pattern is one that maps well onto SQL databases. I personally really like the finder style interface. I use it for many of my Model classes.
The point of patterns is that they provide standard names to talk about common solutions. So for Gateways the common ones are: rows (Row Data Gateway), rows with business logic included (Active Record), and tables (Table Data Gateway). But you are free to use the more general Gateway or vary from any of those. It is just that those are proven to be good solutions, so you need good reasons to vary from them.
Posted: Fri Apr 28, 2006 12:33 pm
by cj5
There are many different ways of doing this, and they are all dependent on what data you are trying to manipulate, or what database you're using. Your question is way to broad. I would suggest you drop back to a more basic book, that helps you learn how to use SELECT statements. I think the book you have might assume that you have working knowledge of SQL. If that's not an option try visiting a site like
this, or any SQL reference manual.
Posted: Fri Apr 28, 2006 2:16 pm
by John Cartwright
cj5 wrote:There are many different ways of doing this, and they are all dependent on what data you are trying to manipulate, or what database you're using. Your question is way to broad. I would suggest you drop back to a more basic book, that helps you learn how to use SELECT statements. I think the book you have might assume that you have working knowledge of SQL. If that's not an option try visiting a site like
this, or any SQL reference manual.
This is an advanced discussion theory question, he isn't worried about SQL syntax...
Re: Design pattern . Table Data Gateway.
Posted: Fri Apr 28, 2006 2:24 pm
by cj5
jmut wrote:But how do I handle multiple table reference..(joins),
and transactions.
Last time I checked JOINS and transactions are query-based, and are trivial, and not theoretical. Sorry, but that's the jist of what I got from his/her question.
Posted: Fri Apr 28, 2006 2:26 pm
by John Cartwright
Do I build another object to represent the connection between tables(object)?
This is what the OP was asking.. he is asking about a design pattern, not how to perform a join or transaction
Back to the topic..
Posted: Fri Apr 28, 2006 3:02 pm
by timvw
A possible abstraction would be that you consider the product/join of two tables as a new sort of table (that has behaviour of the two separate tables.. Multiple inheritance)
The other possibility i see is add ingFindByExternalData methods that accept the column/table to perform the join on... (At first sight it seems that is harder to optimise the generated sql with this implementation.)
Posted: Fri Apr 28, 2006 6:05 pm
by Christopher
I would maintain the straightforward Gateway interface and manage the complexity internally. You will know which fields go with which tables, so update or insert just need to build multiple statements for new/dirty data. You probably want to do transactions. The interface can just have findThis() and findThat() at needed by the application -- not caring what the underlying table layout is.
Posted: Fri Apr 28, 2006 7:26 pm
by Ollie Saunders
are you asking if it is possible to mimic SQL behaviour in PHP classes operating over arrays of data?
cause if you are the answer is yes but why?
Posted: Sat Apr 29, 2006 2:08 pm
by jmut
arborint wrote:.....If you think the finders + insert/update/delete interface makes sense for you then there is no reason why you can't have joins for the finders and do multiple insert/update/delete operations inside those methods. The Gateway pattern is one that maps well onto SQL databases. I personally really like the finder style interface. I use it for many of my Model classes.
....
This is the thing. Of course I could solve the problem somehow adding methods that do this JOIN operations or whatever but is this the pattern way - this way my class will know about different table and stuff which is not correct I think.
I am more toward timvw suggestion.
timvw wrote:A possible abstraction would be that you consider the product/join of two tables as a new sort of table (that has behaviour of the two separate tables.. Multiple inheritance)...
Building object that simulates/presents this join have the knowledge about the to tables and control stuff. I don't not yet how to build such thing gracefully but I will do some more reading on the topic. Just think it is a common problem after all...hence design pattern exist and there is more or less trivial solution.
As always it turns out to be specific

so I will write back when solve my problem

Thank you all.
Posted: Sat Apr 29, 2006 2:08 pm
by jmut
ole wrote:are you asking if it is possible to mimic SQL behaviour in PHP classes operating over arrays of data?
cause if you are the answer is yes but why?
no
Posted: Sat Apr 29, 2006 2:37 pm
by Christopher
I am not sure, but Tim and I may be saying the same thing. I am assuming that because you are using a join that the object itself will contain data from multiple tables. Finder methods will retrieve data from multiple tables, so the insert/update/delete methods need to operate on multiple tables as well. They may just always write all data, or intellegently only write to tables when that data is dirty. This does not require "adding methods" but only adding multi-table logic within the standard Gateway methods.