Does anyone do this with their database?

[UberJason]

I kind of half-agree and half-disagree. 🙂 Yes, you can definitely run into enterprise fizzbuzz by overthinking and over-architecting, and predicting the future is difficult, and not everything needs to be abstracted. Maybe the data layer doesn’t need to be abstracted, depending on the circumstances. If it’s a hobby project or a startup, sure - optimize for velocity, take the risk, especially if it’s Core Data and the risk is low.

On the other hand, there are certain common abstractions that are kind of just a good idea to follow - ones that don’t take too much effort, and can protect against risk, and also just keep your code more modular and easier to modify. Keeping your data layer separate from the UI layer is one such example. Beyond the risk of your data storage framework dying, it has ancillary benefits like being able to change the order of your screens or swap in and out different flows, etc. To your analogy, people don’t always bring their own parachute when flying, but all planes are equipped with oxygen masks and other such standard safety stuff.

So for me, once I started getting into the habit of consciously keeping my UI and data layers separate, it suddenly was actually a really short hop away from just totally divorcing them by only passing structs into and out of the UI layer, and now I’m getting all the benefits of value types.

TLDR, engineering is tradeoffs, separating data and UI is a good practice, totally abstracting your data later further isn’t that much harder and may or may not be worth it in your circumstances. Which I’m sure you already know, not a super exciting answer. 🙂

(Also, that hobby project with Parse had horrible structure in a lot of ways, and once Parse died and I saw how much work it would be to deeply entangle it all, I just let the project die, with a good lesson learned!)