If you started programming back in the day - you were taugh like me to wrap your DB in an interface - but why? Well, some will say it is to make replacing the DB easier; others will tell you it is to make the contract between the App & the DB obvious and clear.
But are these really valid reasons in out 21st Century AI coding paradigm? I'm going to say NO.
With millions of developer world wide writing Apps (not in C++) and many switching to AI coding tools that are rapidly gaining skills - the need for an explisit contract (interface) is not required. Nor needed if you decide to swap DBs in the middle of the river of App versions.
As I did with PortfolioEC version 3.
Interface pattern
Core Purpose:
Decoupling and Abstraction (What vs. How)
Interoperability and Communication
Modularity and Reusability
Standardization (The "Contract")
Simplifying Complexity
I decided to swap out the DB in PortfolioEC because I wanted the capability of true collaborative sharing of DB objects. When I started with SwiftData - I made an assumption that because of the 3 tier archicture (Public, Shared, Private) I would get the sharing that I wanted. OK, well maybe not today - but some day... never came.
So seeing Stewart Lynch's SQLiteData tutorial - Gift Registry... it was so easy to add true collaborative sharing. Waiting on Apple WWDC to anounce SwiftData Collaboration was just too long of a unknown wait.
The AMBIGUOUS use of the word share!
What does it mean for an App to share data ... [this is a fundmental problem - the word has too many similar meanings].
I want sharing between users of my PortfolioEC App to be like a family would share access to the core data and allow others to change or update the shared info at any time. For example my wife and I have shared bank accounts. It is NOT done through a shared bank password. I want my brokerage to understand this modern family relationship - but so few have this feature. PortfolioEC will soon have this family collaborative sharing capability.