13.5 · The repository pattern and cache design

How the rest of the app sees storage decides whether you can change it. A thin repository and a deliberately designed cache keep the framework behind a door.

Mental model. The domain asks for things (users, orders); only the repository knows they live in rows. Caches are a policy (size, age, eviction), not a dictionary.

Boundaries

Repositories and mapping between storage and domain.

1. What is the repository pattern, and why map storage models to domain models? 13.5.1 · L3
   A repository is an object (usually behind a protocol) that offers the rest of the app a collection-like interface to a kind of data: func user(id:) async…

Caches

Memory and disk caches, TTL and eviction.

1. How do you design a cache: memory and disk layers, TTL, eviction, and what to key it by? 13.5.2 · L5
   A cache trades memory or disk for time, and its policy is the design. Decide five things. Key: everything that changes the value, for example the URL and the…

More in Persistence & data

• 13.1 · Where data belongs, and the Keychain
• 13.2 · SQLite fundamentals: transactions, WAL, constraints, indexes and migrations
• 13.3 · The Core Data stack, contexts and faults, concurrency, and migrations
• 13.4 · SwiftData: models, contexts, predicates, actors and schema evolution
• 13.6 · Crashes mid-write, integrity, backups and data protection
• 13.7 · Syncing data across devices: conflicts, tombstones and CloudKit
• 13.8 · UserDefaults surprises and FileManager essentials
• 13.9 · Reading query plans, typing and NULL, WAL locking, savepoints and full-text search
• 13.10 · Merge conflicts, faults and batch requests, delete rules, and the SwiftData context
• 13.11 · Keychain status codes, detecting corruption, an LRU cache and library trade-offs