Little different perspective, Core Data tends to work drop dead easy for simple stuff. Small data set with simple functionality should work straight out of the box easy.
And there is nothing wrong with creating a manual array of managed objects from a Core Data result set. I personally wouldn't stray from Core Data until you hit pain points, performance problems or functionality limitations. Core Data is like autolayout in that, it generally works very well for simple things (which it sounds like you're after). Just my $0.02, Luther On Fri, Aug 5, 2016 at 3:57 PM Quincey Morris < quinceymor...@rivergatesoftware.com> wrote: > On Aug 5, 2016, at 07:46 , Trygve Inda <cocoa...@xericdesign.com> wrote: > > > > Somehow this seems easier to do without Core Data. > > If you’ll accept my opinion as commentary and not anything more dire, I’d > say that your proposed course of action is based on several clearly > undesirable options: > > 1. For 5,000 records, I don’t think there’s enough data to justify using > Core Data at all, given the amount of development pain you can expect. Core > Data is famous for pain. Your project may be the exception, where > everything goes smoothly and Core Data brings a smile to your face, but I > wouldn’t bet on it. > > 2. For 5,000 records, you do need a storage solution. If non-local storage > is possible, then I’d suggest you look very seriously at CloudKit. It’s > what Apple did *instead* of making Core Data usable for mere mortals. You > may still need some kind of local persistence, but if only a few hundred > records are needed locally, keeping them (or enough of their properties to > populate your table view) in RAM may be enough. > > 3. If you must have local persistent storage, then I’d suggest one of the > 3rd party databases. I recommend these behind CloudKit only because over > time 3rd party libraries tend to embroil you in update compatibility woes, > whereas sticking with Apple software means you know where you stand with > updates and backward compatibility. > > 4. NSXxxController is a glue object, which exists only to let you avoid > writing code that’s largely boilerplate. IMO it’s a terrible mistake to it > them as an app *design* element. These classes are pure implementation. > > 5. The NSXxxController functions of sorting and filtering have their > counterparts in Core Data and also in any decent persistent storage system > that has database-like semantics. No need to think about NSXxxController. > > 6. Depending on what is involved with your “interestingness” property (the > one that defines the subset of 200 or so records), you may be able derive > it in the NSTableView data source (by logically combining two groups of > records), or by providing a derived property, or by using Core > Data/database fetch predicates, or by storing something in the database > itself. What you do depends on the complexity of the property, but none of > the options need NSXxxController. > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com > > This email sent to lutherba...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
