Today we will dive in some of the data source patterns for enterprise applications
A. Table Data Gateway
A Table Data Gateway holds all the SQL for accessing a single table or view: selects, inserts, updates, and deletes. Other code calls its methods for all interaction with the database.
A.1 How it works ?
A.1.1 Insertion Part
A Table Data Gateway has a simple interface, usually consisting of several find methods to get data from the database and update, insert, and delete methods. Each method maps the input parameters into a SQL call and executes the SQL against a database connection.The Table Data Gateway is usually stateless, as its role is to push data back and forth.
A.1.2 Retrieving Part
Here we have a problem with that patterm because, it will return multiple items even for a simple findById(id) method !
We have alternatives for that :
-Map: A map works, but it forces data to be copied out of the record set that comes from the database into the map. But the problem with a Map is that it can not be used everywhere !
-DTO: However a DTO can, yes we have to create another object but a DTO can be used or processed but much more environments
A.2 When to use it ?
According to the author :
I find that Table Data Gateway is probably the simplest database interface pattern to use, as it maps so nicely onto a database table or record type. It also makes a natural point to encapsulate the precise access logic of the data source. Table Data Gateway works particularly well with Table Module, where it produces a record set data structure for it.
B. Row Data Gateway
If it is not white, it's dark 😂
A Row Data Gateway gives you objects that look exactly like the record in your record structure but can be accessed with the regular mechanisms of your programming language. All details of data source access are hidden behind this interface.
B.1 How it works ?
B.1.1 Behind the hood
A Row Data Gateway acts as an object that exactly mimics a single record, such as one database row. In it each column in the database becomes one field. The Row Data Gateway will usually do any type conversion from the data source types to the in-memory types, but this conversion is pretty simple. This pattern holds the data about a row so that a client can then access the Row Data Gateway directly
But we have the problem of how to generate a Row data gateway ?
B.1.2 Creating a Row Data Gateway
With a Row Data Gateway you’re faced with the questions of where to put
the find operations that generate this pattern. You can use static find methods, but they preclude polymorphism should you want to substitute different finder methods for different data sources. In this case it often makes sense to have separate finder objects so that each table in a relational database will have one finder class and one gateway class for the results
Like you see in the image below, we create a Finder that will generate for us Row data gateway for the Person model
B.2 When to use it ?
I use Row Data Gateway most often when I’m using a Transaction Script . In this case it nicely factors out the database access code and allows it to be reused easily by different Transaction Scripts. A Row Data Gateway
should contain only database access logic and no domain logic.
Conclusion : The choice of Row Data Gateway often takes two steps: first whether to use a gateway at all and second whether to use Row Data Gateway or Table Data Gateway. 😉
Top comments (0)