How do you use a Table Data Gateway template that includes a one-to-many relationship?

Question

I tried to learn more about design patterns by reading Martin Fowler's Enterprise Application Architecture Patterns. I came across a Data Data Gateway Template and wondered how you use it if you have operations with multiple tables?

I understand that each table will have its own class. Each class will have SQL statements to access one table, but what happens when some of my statements rely on other tables?

Here is a concrete example. If I have a one-to-many relationship between two tables, for example Questions and Choices (multiple choice questions), I would like to get a question with all its variations. Then I would have a QuestionGateway class with the find() method, but would I also have a ChoiceGateway class with the findByQuestionId() method to get all the answers?

Answer 1

Your concept of how this template looks is fair for money. Your question suggests that you also understand the more important idea of ​​the type of problems that the pattern should solve.

The Data Data Gateway template is not intended for complex data models where associated data is stored in multiple tables. It is intended for simple data that does not have any links with other data in your database. This is a return from days of specialty stores with key values ​​when people wanted to use ACID guarantees for data that was not used for the relational model. As you noticed, the pattern worsens as soon as you care about the relationship between your data. If you imagine ever wishing to JOIN this table with another, do not use this template. Since the whole point of the relational model is to preserve the relationships between the data, in practice it is usually avoided.

Answer 2

I would suggest a slightly more flexible interpretation of this pattern. You do not have to feel limited or make strange decisions in order to be 100% compatible with the definition of patter.

Please do not get me wrong. I do not suggest throwing patterns. I actually suggest using them appropriately.

Answering your question:

• If there are not many interdependencies between your ChoiceGateway and QuestionGateway , it is normal if they are separated.
• If there are interdependencies, and it is better that these tables "join" in terms of business logic, you can create something like a "view", for example, call it QuiestionView . Thus, your business logic may be a little more understandable, and all specific DB files will be encapsulated in a specific view.

Basically, it's all about useful abstractions. If you are comfortable working with these tables, independently define independent gateways with some possible duplication. If you need "all in one place", just define a high-level abstraction.

By the way, the template itself is abstract not only for tables, but also for viewing. Therefore, I see no reason why you cannot create a higher level abstraction using a specific approach.

The table data gateway contains all the SQL to access a single table or view