NSDictionaries vs. custom objects with properties, what's your take?
<p>I'm writing an App that basically uses 5 business entities, A, B C, D and E</p>

<ul>
<li>A has some properties and holds a list of B's</li>
<li>B has some other properties and a list of C's and a list of D's</li>
<li>C has some other properties and a list of D's and a list of E's</li>
<li>D has only a few properties</li>
<li>E has only a few properties</li>
</ul>

<p>There is no inheritance between any of them.
There's no real business logic involved, the objects are created, populated, and then accessed read-only, no further manipulations. </p>

<p>My natural coding style would be to go object oriented and write classes for each of those entities, use NSArrays for the lists, and have the mentioned properties synthesized.</p>

<p>It would make the code readable.</p>

<p>But another approach seems obvious too: only use NSDictionaries and NSArrays, and working with keys/values instead of properties. This seems more efficient, and somehow "closer" to iPhone-style programming to me... but obviously leads to less readable code. Another advantage is there's no additional custom encoding/decoding for serialization required (persisting state to disk, using JSON, ...)
So on the paper, it speaks for the latter approach, on the other hand, it still feels somehow awkward NOT to use custom objects... </p>

<p>Is this really just <strong>a matter of taste question</strong>? Or are there maybe other arguments in favour/against one of the approaches? Is only using Dictionaries better memory/performance-wise? Is it the preferred "Apple Coding Style"? (I'm coming from Java/C#).</p>
