Disclaimer: This answer will not address the linked question specifically. Rather, it will offer some clarification on what CoreData is and isn't, and how this compares to things it might easily be confused with.
Before we talk about what CoreData is, let's talk about what CoreData isn't.
- CoreData isn't a database. CoreData happens to use SQLite as a means for storing objects on disk, but it is not a database. It has a means of representing relationships between objects, and this may feel similar to a database schema (and is frequently referred to as a database schema), but the schema of the backing SQLite database doesn't necessarily directly match the relationships you've set up in your CoreData data model... at least not in the way you might expect if you're thinking of a traditional database.
- CoreData isn't a UML. UMLs are to CoreData what comments are to executable code. While comments are a useful way of explaining what the code itself does, the comments aren't actually executable code. And the code that the comments are paired with may or may not actually do what the comments claim them to do. A UML is an attempt to document a program, lay out a map of its classes, etc., but the actual implementation may or may not actually match the UML. Moreover, you can change the UML without changing the code, and you can change the code without changing the UML. This is not what CoreData is. CoreData isn't documentation. When you create objects in CoreData, you're actually creating code.
Importantly, CoreData does not even exist outside of your Xcode project when you are writing Objective-C or Swift applications. (I am unaware whether or not you can use CoreData with other languages.)
When you create a new project in Xcode, on the absolute first screen, there is a check box allowing you the option to use CoreData:
And when you are using CoreData in your project, you will have a file with an .xcdatamodel extension in your Project Navigator:
And when you click on the file, your editor gives you Xcode's CoreData model editor. This is where the screenshot from the linked question comes from. There are multiple views within this editor.
It's important to note that by simply setting up entities within CoreData, you are writing code. This is the exact same as when you drag and drop a button onto a view in an interface builder. You're actually writing code when you do this.
For example, let's say I drag and drop in the visual interface builder and set up the following interface:
Well, like it or not, despite not using my keyboard (other than typing the text for the label/button), I've actually written several lines of code.
The code I wrote looks something like this:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<document type="com.apple.InterfaceBuilder3.CocoaTouch.Storyboard.XIB" version="3.0" toolsVersion="6254" systemVersion="14B25" targetRuntime="iOS.CocoaTouch" propertyAccessControl="none" useAutolayout="YES" useTraitCollections="YES" initialViewController="BYZ-38-t0r">
<dependencies>
<plugIn identifier="com.apple.InterfaceBuilder.IBCocoaTouchPlugin" version="6247"/>
</dependencies>
<scenes>
<!--View Controller-->
<scene sceneID="tne-QT-ifu">
<objects>
<viewController id="BYZ-38-t0r" customClass="ViewController" sceneMemberID="viewController">
<layoutGuides>
<viewControllerLayoutGuide type="top" id="y3c-jy-aDJ"/>
<viewControllerLayoutGuide type="bottom" id="wfy-db-euE"/>
</layoutGuides>
<view key="view" contentMode="scaleToFill" id="8bC-Xf-vdC">
<rect key="frame" x="0.0" y="0.0" width="600" height="600"/>
<autoresizingMask key="autoresizingMask" widthSizable="YES" heightSizable="YES"/>
<subviews>
<label opaque="NO" userInteractionEnabled="NO" contentMode="left" horizontalHuggingPriority="251" verticalHuggingPriority="251" fixedFrame="YES" text="Code Review is AWESOME!" textAlignment="center" lineBreakMode="tailTruncation" baselineAdjustment="alignBaselines" adjustsFontSizeToFit="NO" translatesAutoresizingMaskIntoConstraints="NO" id="gQP-SH-P1b">
<rect key="frame" x="16" y="20" width="568" height="59"/>
<fontDescription key="fontDescription" type="boldSystem" pointSize="24"/>
<color key="textColor" red="1" green="1" blue="1" alpha="1" colorSpace="custom" customColorSpace="calibratedRGB"/>
<nil key="highlightedColor"/>
</label>
<button opaque="NO" contentMode="scaleToFill" fixedFrame="YES" contentHorizontalAlignment="center" contentVerticalAlignment="center" buttonType="roundedRect" lineBreakMode="middleTruncation" translatesAutoresizingMaskIntoConstraints="NO" id="L5z-hi-FnJ">
<rect key="frame" x="225" y="158" width="150" height="60"/>
<color key="backgroundColor" red="0.50196081400000003" green="0.0" blue="1" alpha="1" colorSpace="calibratedRGB"/>
<fontDescription key="fontDescription" type="system" pointSize="19"/>
<state key="normal" title="This is a button!">
<color key="titleColor" white="1" alpha="1" colorSpace="calibratedWhite"/>
<color key="titleShadowColor" white="0.5" alpha="1" colorSpace="calibratedWhite"/>
</state>
</button>
</subviews>
<color key="backgroundColor" white="0.0" alpha="1" colorSpace="calibratedWhite"/>
</view>
</viewController>
<placeholder placeholderIdentifier="IBFirstResponder" id="dkx-z0-nzr" sceneMemberID="firstResponder"/>
</objects>
</scene>
</scenes>
</document>
Furthermore, from Interface Builder, I can set up properties for classes. Dropped a button on that view controller? Now I can set up the view controller's backing class to have a property for that button as well as a method to handle the button being tapped.
I can do all this without using my keyboard.
Okay, so what's the point of me talking about interface builders?
With CoreData, we're doing the same thing!
Model. View. Controller.
There's three parts to this design paradigm, right? With Interface Builder, we design our view and hook it up to the controller.
CoreData is like a visual interface builder for the model part of MVC. When you create your CoreData model, you're actually making changes to your program--to your executable source code. The image included in the linked question isn't just a road-map to the application that is a nice visual representation of what the data model is supposed to look like. The image included in the linked question ACTUALLY IS THE IMPLEMENTATION OF THE DATA MODEL!
Here, I've used CodeData two set up two entities with three attributes each:
And a relationship is described from Entity1 to Entity2.
But this isn't just a visual representation of what I want to implement. These attributes actually have types:
And now, without writing any other code, I can immediately start using these entities in my CoreData application:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
NSManagedObjectContext *context = [self managedObjectContext];
NSManagedObject *entity1 = [NSEntityDescription insertNewObjectForEntityForName:@"Entity1" inManagedObjectContext:context];
[entity1 setValue:@42 forKey:@"attribute2"];
NSError *error;
if (![context save:&error]) {
#if DEBUG
NSLog(@"Error saving entity: %@", error.localizedDescription);
#endif
}
return YES;
}
I can load from and save to disk using CoreData. It's a simple as that, and CoreData is extraordinarily efficient at reading from and writing to disk, and because it is backed by SQLite, there are ways to effectively seek out specific Entities you've saved using CoreData.
But using CoreData in this manner is actually quite rare. What is more likely is to use Xcode and CoreData to generate classes based off of your CoreData entities:
Following this series of steps:
Will add the following files to your Xcode project:
And the generated files will look just like this:
Entity1.h
#import <Foundation/Foundation.h>
#import <CoreData/CoreData.h>
@class Entity2;
@interface Entity1 : NSManagedObject
@property (nonatomic, retain) NSData * attribute1;
@property (nonatomic, retain) NSNumber * attribute2;
@property (nonatomic, retain) NSNumber * attribute3;
@property (nonatomic, retain) Entity2 *relationship;
@end
Entity1.m
#import "Entity1.h"
@implementation Entity1
@dynamic attribute1;
@dynamic attribute2;
@dynamic attribute3;
@dynamic relationship;
@end
Entity2.h
#import <Foundation/Foundation.h>
#import <CoreData/CoreData.h>
@interface Entity2 : NSManagedObject
@property (nonatomic, retain) NSNumber * attribute1;
@property (nonatomic, retain) NSDate * attribute2;
@property (nonatomic, retain) NSString * attribute3;
@end
Entity2.m
#import "Entity2.h"
@implementation Entity2
@dynamic attribute1;
@dynamic attribute2;
@dynamic attribute3;
@end
And they will look like that every time. The only difference is that Xcode will give you the option between using NSNumber or primitive data types for particular properties (integer types, floating point types, booleans).
I don't need to see the .h or .m files that Xcode has generated for the user unless the user has then modified these files in some way (which is common).
So, now that you've scrolled passed the lesson on what CoreData is, you're ready for the meat of the answer...
Is the linked question on-topic? I don't know.
But we can review poorly named classes, poorly named properties, poorly named variables, etc. We can review variables that are excessive and unnecessary. We can review variables that should be of a different type. We can review information that might be missing. ("I see your person class has a firstName property, but no lastName property. You should probably include a lastName property.")
Moreover, let's say we had a class called Family and a class called Person. Family could have a Person property called Father, and a Person property called Mother, and three Person properties called OldestChild, MiddleChild, and YoungestChild. And in reviewing these two classes, we could point out that the Family class probably isn't well designed because different families have different configurations... varying number of children, step-parents, step-children, half-siblings, etc.
What's the difference between reviewing the data model that someone wrote by hand with their keyboard to map these Family and Person classes versus reviewing the data model that someone built with CoreData? And in answering this question, keep in mind everything we've already reviewed in this post: CoreData is not a database schema; CoreData is not a UML; CoreData is an actual data model implementation.
