Week 063 — Mapper Classes and Missing IDs

The mapper pattern solves the DTO transformation problem. Then a missing ID surfaces.

Week of February 2, 2026

Progress

The item API refactor raised a design question: when the UI sends a single payload and the service layer needs two separate DTOs from it, where does the transformation happen? Grok pointed to mapper classes — a pattern where transformation logic lives in its own class rather than in a DTO (too heavy) or a factory (wrong purpose). An ItemDTOMapper class was created to own this.

The decision on whether the mapper should look up data from the store to complete the DTOs — filling in fields that the UI payload doesn't include — was settled against. The mapper takes what it's given and maps it. Callers are responsible for passing complete data. This keeps the mapper stateless and aligned with the single responsibility principle.

The LostInstanceID was missing from the POST payload from item.php. The item page was sending item data but not including the ID of the specific lost instance record, which the service layer needs to create a usable ItemLostInstanceDTO. The fix: have the API look it up and add it to the array before dispatching.

Next Week

Complete the item API refactor.