Design pattern . Table Data Gateway.

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:

Design pattern . Table Data Gateway.

Post 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
User avatar
cj5
Forum Commoner
Posts: 60
Joined: Tue Jan 17, 2006 3:38 pm
Location: Long Island, NY, USA

Post 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?
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
cj5
Forum Commoner
Posts: 60
Joined: Tue Jan 17, 2006 3:38 pm
Location: Long Island, NY, USA

Post 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.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post 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...
User avatar
cj5
Forum Commoner
Posts: 60
Joined: Tue Jan 17, 2006 3:38 pm
Location: Long Island, NY, USA

Re: Design pattern . Table Data Gateway.

Post 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.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post 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..
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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.)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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?
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Post 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.
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Post 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
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
Post Reply