I’ve been using CoreData myself for a few years now and thought it’s a great example where you have the managed objects being separated from the structs. In theory you would be able to use these structs throughout your app, hiding the CoreData stack. Later on you’re using the managed objects directly in your views though with the FetchRequest etc. I find it super convenient to use as well, but it violates some principles making your views dependent on CoreData.
I feel kind of stuck, on the one hand there’s a lot of tutorials using this approach. And it seems Apple is keep adding more support for this approach as well. On the other hand what I hear from some of my clients is that they don’t want to rely on the CoreData stack, to have the ability to swap it out for something else.
Is there a general consensus on this approach? Would it be in this case that the dependency is negligible since it’s such a big part of the ecosystem?
Hi @wessoll
That’s a great question, but there really is no right answer. It all depends on what you need to build. CoreData works great with Apple’s frameworks, it has a lot of convenience since Apple extends it to match other frameworks, like SwiftUI and CloudKit. So it’s a great solution when you don’t have any constraints on what to use.
On the other hand, you could possibility want to use a cross-platform solution, like Realm. This would allow you to reuse and match a lot with other platforms. But just like CoreData, if you’re concerned with the view depending on the database, you’d also have to create a layer of abstraction between the two.
So it all comes down to what your prerequisite and specifications are. Creating this layer of domain and abstraction between your app and the database means the project will have more code and take longer to complete and maintain. However – and obviously, I’m talking about my own professional experience – I’d say it’s quite uncommon to have to change database stacks after the app has launched. Sure, there are cases that might require this, but you’d probably have to refactor a lot of the domain code to handle this migration too.
1 Like