StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Fetch request properly belong to the individual controllers in the Model-View-Controller pattern. A fetch returns the specific information, in the specific order, required by each individual view. Each fetch is customized for the needs of each particular view. As such, putting all of an app's fetches in a single object would break encapsulation instead of enhancing it. Only fetched properties and fetched relationships belong in the data model itself.</p> <p>The managed object context performs the function of the data object in simple apps. It implements all the functions necessary to get information in and out of the Core Data stack e.g. <code>- objectWithID:</code>. Much of the time, all you need to do is pass the context to controllers and let them configure fetches to it. </p> <p>If your app is large or has multiple context, you can always wrap up the context/s in a custom manager class with various accessors and convenience methods to make the Core Data operations run more smoothly. You can legitimately and safely implement the manager class as a singleton to make accessing it everywhere in the app easy. </p> <h2>Edit:</h2> <p>The code looks okay except for the mutable copy. It's pointless and will leak memory. The <code>entities</code> array is only needed for one line and it's autorelease. The <code>Client</code> objects retention is managed by the context. You should test the error and at least log it for debugging. </p> <p>You do want to avoid "get" and "set" for method names that are not accessors. The runtime looks methods that begin with "get" and "set" to find accessors. By convention, all method names start with lower case. You might want to make the method name more descriptive so that it auto-comments when you read it months down the road. </p> <p>So:</p> <pre><code>[theCoreDataDal GetClient:vaugelyNamedString]; </code></pre> <p>to</p> <pre><code>[theCoreDataDal clientWithClientID:vaugelyNamedString]; </code></pre> <p>The problem your going to run into with trying to cram everything into one object is that the fetches are usually unique and configured for the needs of a specific interface. Moreover, you usually start with a fetch to find specific objects but then you spend the rest of the time walking relationships based on input unknown until runtime. </p> <p>Core Data is the data access layer. Most of the code you write for Core Data is actually controller code. There is nothing conceptually problematic about this <code>GetClient</code> method but <em>how often are you going to execute this particular fetch?</em> </p> <p>When I create a Data Model Manager object, I use it largely to store boiler plate code. For example, while each fetch request is unique, they all start out the same with an entity description so I autogenerate methods to return the basic fetch for each entity and put that in the manager. Then I have another boiler plate method to actually perform the fetch. In use, a controller ask the manager for a fetch object for a specific entity. The controller customizes the fetch and then sends it back to the manager to perform the fetch and return the results. </p> <p>Everything boiler plate is in the manager and everything customized is in the controller. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload