What is the structural difference between the Row Data Gateway and Table Data Gateway patterns, and how does that difference affect how many gateway objects exist at runtime for a table with 10,000 rows?

## What a single instance represents Row Data Gateway and Table Data Gateway are both **pure data-access patterns from PoEAA** — unlike Active Record, neither one holds business logic — but they differ in what a single instance represents. - **A Row Data Gateway** object wraps exactly one row: it has instance fields for that row's columns and instance methods (`insert()`, `update()`, `delete()`) that act on that specific row, so working with a result set of 500 rows means instantiating 500 gateway objects, one per row, each independently responsible for persisting itself. - **A Table Data Gateway**, by contrast, is a single class representing the whole table, usually with no per-row state at all; you call one shared instance's methods — `findById(id)`, `insert(rowData)`, `update(id, rowData)` — passing in whatever data identifies or describes the row, and it hands back plain records (a map, an array, a lightweight DTO) rather than a typed row object. For a table with 10,000 rows, Row Data Gateway usage could mean up to 10,000 short-lived objects in memory during a batch operation, while Table Data Gateway usage means exactly one gateway instance regardless of how many rows you touch. | Dimension | Row Data Gateway | Table Data Gateway | |---|---|---| | A single instance | wraps exactly one row | represents the whole table | | Hands back | a typed row object | plain records: a map, an array, a lightweight DTO | | For a table with 10,000 rows | up to 10,000 objects | exactly one gateway instance | | Pairs naturally with | a Domain Model | Transaction Script | ## Why both exist The reason both patterns exist as distinct options is to give the rest of the codebase a clean seam for pure data access without forcing business logic to live in the same class — the opposite trade Active Record makes. - **Row Data Gateway** is meant to pair with a separately-defined Domain Model: you'd have a rich `Order` class holding business rules, and a companion `OrderRowGateway` handling the actual SQL, with the `Order` delegating to the gateway rather than doing SQL itself. - **Table Data Gateway** pairs naturally with Transaction Script — code organized as a sequence of procedures per business transaction rather than behavior-rich objects — since Transaction Script just needs a straightforward way to read and write rows without any notion of object identity per row. ## The trade-off The trade-off between the two is largely about **scale and shape**. - Row Data Gateway gives you a typed object per row that's easy to pass around and matches naturally with a domain object that also represents one row, but instantiating one object per row becomes expensive for large scans: a report touching hundreds of thousands of rows creates hundreds of thousands of gateway objects, adding real allocation and garbage-collection pressure for no benefit if nothing besides simple reads is happening. - Table Data Gateway avoids that churn entirely — one instance serves arbitrarily many rows — but the caller has to work with loosely-typed records rather than a well-typed row object, pushing more responsibility for interpreting field names and types onto calling code, and losing some of the discoverability an IDE gives you with a typed class. ## Failure modes The failure modes follow directly from misapplying either one. 1. **Row Data Gateway in a hot path.** Reaching for Row Data Gateway in a hot, high-volume batch or reporting path is the classic performance trap: profiling such code often reveals object-allocation overhead entirely attributable to instantiating one wrapper per row rather than to the actual database query. 2. **Table Data Gateway against a rich domain.** In the other direction, reaching for Table Data Gateway when the surrounding code is organized as a rich Domain Model creates friction, since the domain objects want to work with typed collaborators, not raw maps, forcing extra translation code at every call site — effectively reinventing Row Data Gateway or Data Mapper piecemeal. ## Where it shows up A concrete real-world echo of this split shows up in older enterprise Java and .NET systems built before ORMs like Hibernate or Entity Framework were dominant: .NET's ADO.NET `TableAdapter` and `DataTable` constructs behave much like a Table Data Gateway, handing back loosely-typed rows for a whole table, while hand-rolled DAO layers pairing one gateway class per persistent domain object in Java systems of the same era resemble Row Data Gateway paired with a Domain Model. Recognizing which one a codebase has chosen — and why — is really about recognizing whether the surrounding code is procedural (Transaction Script) or object-oriented with real domain behavior (Domain Model), since that surrounding style is what each gateway pattern was designed to serve.