Apple Developer Connection
Member Login Log In | Not a Member? Contact ADC

< Previous PageNext Page > Hide TOC

Choosing Class Properties

When you add attributes to entities in EOModeler, they are marked as class properties (denoted by the diamond in an attribute’s row). When an attribute is marked as a class property, accessor methods for that attribute are included in that class definition when you generate source files for the class using EOModeler. When instances of an enterprise object are created, the data that maps to an attribute is fetched from the database and stored in the enterprise object instance, so you should mark attributes only as class properties if their data is needed in an enterprise object instance.

As a general rule, you should mark attributes as class properties only if their values are meaningful to a particular enterprise object’s business logic or if their values are displayed in the user interface. An attribute that won’t be used in business logic or that users don’t need to see or manipulate shouldn’t be marked as class properties.

Database artifacts such as primary and foreign keys shouldn’t be marked as class properties. There are exceptions to this rule, such as when you provide custom primary keys, but they are rare. Enterprise Objects handles key generation for you, so these keys aren’t necessary in your business logic classes. Also, it is rare that a primary key would contain data valuable to a user. (This generally reflects poor schema design, such as when a driver license number is used as a table’s primary key.)

In the Listing entity described in “Reference Entity,” the bedrooms, bathrooms, and address properties are selected as class properties, while the entity’s primary key, listingID, is not marked as a class property. The bedrooms, bathrooms, and address properties contain data that is meaningful to the application’s users; the listingID property does not.

A consideration, especially for advanced users, is to ensure that a given entity doesn’t have any redundant attributes that are marked as class properties. A common mistake when building data models that use entity inheritance is to mark multiple attributes as class properties when the attributes in fact represent the same data, such as can occur when flattening attributes and relationships. This issue is discussed in more detail in EOModeler User Guide.



< Previous PageNext Page > Hide TOC


Last updated: 2007-07-11




Did this document help you?
Yes: Tell us what works for you.

It’s good, but: Report typos, inaccuracies, and so forth.

It wasn’t helpful: Tell us what would have helped.
Get information on Apple products.
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Copyright © 2007 Apple Inc.
All rights reserved. | Terms of use | Privacy Notice