Design pattern . Table Data Gateway.
Moderator: General Moderators
Design pattern . Table Data Gateway.
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
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
I don't know how to simplify this more.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?
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
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)
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.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
This is an advanced discussion theory question, he isn't worried about SQL syntax...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.
Re: Design pattern . Table Data Gateway.
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.jmut wrote:But how do I handle multiple table reference..(joins),
and transactions.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
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.)
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.)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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)
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
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.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.
....
I am more toward timvw suggestion.
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.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)...
As always it turns out to be specific
Thank you all.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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)