Question

I try to explain.
Simple sample project, with a Person class managed, for example, by Core Data.
I have many UITableViews that shows the data (one showing all persons, permitting to add, remove, update persons, another showing the middle age, another showing the persons grouped by same name…these are only some example, it doesn’t matter).
Sure, I don’t want to write the core data code inside all the viewcontrollers.
What would you do in a situation like this to write more maintainable code?

• A singleton “PersonManager” class, with (for example) a mutableArray with all persons, insert-remove-update methods, a NSFetchedResultsController ecc ecc…

• Class methods on the Person object? Something like “NSArray *array = [personObject allPersons];” and methods add-remove-update? The class knows how to load itself from memory ecc ecc…?

Or what?

Thank you
Fabio

Answer 1

I once read a very good book on design patters and OOP which stated that every class that you make and are tempted to call it “manager” is rubbish. I can’t remember the book, but it matters less. The point is, every data object should be able to manage itself and manage its relationships (for example a person object could have an addFather: or addFriend: method). And a Core Data tip: use categories to implement additional methods to the automatically generated data object classes, it will make your life much easier when you add new relations or properties in Core Data.

So, in your case, you would need a data object that has all persons tied to it. You can call it AgendaDO or whatever. This object will have methods to add, remove persons, but also to get all the persons in a specific order, to sort only specific persons and so on.