NSDictionary против пользовательского объекта

Это действительно зависит от того, насколько вы ожидаете, что ваша модель данных изменится. Работа с изменениями, когда у вас есть настраиваемая модель данных на основе классов, может быть сложной, особенно когда у вас есть архивы (вещи NSCoding) с разными версиями модели (в уже отправленных версиях вашего приложения), вы должны быть очень осторожны, чтобы обеспечить обратную совместимость и избежать неприятных сюрпризов во время выполнения. В этом отношении модели на основе NSDictionary, как вы говорите, более гибкие. Однако они не допускают всех настраиваемых проверок и поведения, которые делают пользовательские классы. Кроме того, пользовательские классы делают модель данных более явной для кодеров, незнакомых с кодом. По моему опыту, разработчики часто проявляют небрежность (особенно неопытные) при работе с моделями на основе NSDictionary, что может быстро привести к непонятному беспорядку, поэтому, если вы опустите это маршрут, хорошо документируйте и будьте дисциплинированы!

Обычно у меня есть набор моделей предметной области, которые лучше подходят для подхода MVC к разработке iPhone. Наличие определенных объектов также позволяет вам намного проще обеспечивать безопасность типов, а также снижает сложность в долгосрочной перспективе. Если у вас есть NSDictionaries, содержащие NSArrays и другие NSDictionaries и т. д. и т. д. для представления вашего графа объектов, он может очень быстро стать неуправляемым.

Если вам нужен доступ только для чтения и не нужны методы, вы можете сделать следующее:

@interface NSDictionary (MyClassCategory)
-(NSString*) someField;
@end

@implementation NSDictionary (MyClassCategory)
-(NSString*) someField {
    return [self objectForKey:@"someField"];
}
@end

typedef NSDictionary MyClass;

И используйте его:

 MyClass* myClass = ...;
    NSString* value = [myClass someField];