|
I literally have just started the Core Data lesson, but I am very excited to learn about using it. My theoretical question is that prior to this lesson Paul has emphasized the use of structs to store data, and having a single class to hold a reference to groups of structs that can be used across all Swift UI views, which I think I understand. The problem I am thinking about is the following: Lets say you have a sports app with the following data model. There is a single instance of class League which is shared across all views. The league has an array of [Team] where each Team is a struct. Each Team has two arrays, one of [Coach] where each Coach is a struct with name, id, number, etc, all basic property types, and [Player] where each Player is a struct with properties of name, id, number, and various stats. etc. Each view accesses the various properties to display what is wanted, etc. Now, Core Data uses classes for each entity, and not structs and as far as I can figure out, cannot store structs directly due to limited types. How do you make the data model for the sports app work with Core Data and maintain the use of the structs as recommended in Swift? I searched forum and google and could not clearly find an explanation that explains the theory without going into a lot of specific code. |
|
The difference is between value type (struct) and reference type (class). Let's say you have a player struct and pass it to a different view/class/whatever. In this case a copy is passed and not the original player struct. If you make any changes to the passed player struct it's only changed on the copy and not on the original player struct. If you use a player class and pass it to something only a reference is passed and any changes on the player are done on the player itself. So to be clear. Depending on what you're trying to achieve you use either a struct or a class. Core Data uses classes because you want to have only one instance of this class (f.e. player) so that changes are made to the original instance. You don't need to maintain the use of structs just because it "is recommended in Swift". You use them when it's appropriate. |
|
Thanks for your response about value vs reference. Lets assume I want to use structs in this data model not classes, since I want to be sure the underlying data is only changed in the copy I am working with, so then how to you use this data model with Core Data? |
|
Frankly speaking? If you use Core Data, you don't. Core Data delivers a whole lot more functionality than just the data model. For example, it can undo your changes, has query functionality, manages your relationships, etc.. I don't know exactly your use case but what you could do is create an extension on your NSManagedObject class which gives back a struct on which you can work on. Then you create another function which accepts your struct with your changes. But this is completely pointless as you can work directly on the ManagedObject and if you don't want to accept the changes you can undo the changes before saving them. It's just an overhead you would create without a real benefit. As a HWS+ member you have access to the UltimatePortfolioApp which uses Core Data. Even Paul doesn't use structs for the ManagedObjects. My suggestion is, watch this course and you will get much more answers from it than I can write in this single post. |
|
SPONSORED Transform your career with the iOS Lead Essentials. This Black Friday, unlock over 40 hours of expert training, mentorship, and community support to secure your place among the best devs. Click for early access to this limited offer and a free crash course.
Sponsor Hacking with Swift and reach the world's largest Swift community!
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.