Модельные классы - какого черта они на самом деле имеют в виду?

Question

Я действительно не могу понять объекты Model в MVC. Интересно, почему мы не можем просто работать с массивами и словарями и массивами словарей?

Я понимаю, что они представляют «данные», которыми манипулируют и работают мои другие классы. Но как правильно их строить? Предположим, у меня есть список, который я хочу прочитать и отобразить в виде таблицы. Я мог бы просто загрузить его непосредственно в свойство массива в моем методе viewDidLoad и затем использовать его, верно? Почему я хочу использовать класс Model и как мне его построить?

Кроме того, любые ссылки на ресурсы / блоги там, которые объясняют этот пункт, будут с благодарностью!

Answer 1

Вы абсолютно можете работать со словарями и массивами - нет ничего плохого в том, чтобы использовать их как часть (или все) вашей модели данных. NSManagedObject Core Data очень похож на словарь. Но иногда вы хотите, чтобы объекты вашей модели делали больше, чем просто хранилище данных - вы могли бы также, чтобы они знали что-то о том, как различные биты данных связаны друг с другом, работают с данными и т. Д.

Подумайте, как бы вы представили человека в своей модели данных. Может быть словарь, верно? С такими ключами, как firstName, lastName, middleName, address, phone, email, dateOfBirth ... Если вы используете простой старый словарь, изменяемый или нет, вы просто сохраняете соответствующее значение для каждого ключа, и все готово. Если это действительно все, что вам нужно, все готово.

С другой стороны, вы можете получить много другой информации из этих полей без необходимости хранить дополнительные данные. Если вы создаете собственный класс Person, вы можете дать ему такие ключи, как fullName, age, initials, monogram и vCard. У пользовательского класса могут быть методы для каждого из них, которые манипулируют хранимой информацией, чтобы получить соответствующие значения. Пример:

- (NSString*)fullName
{
    return [NSString stringWithFormat:@"%@ %@ %@", self.firstName, self.middleName, self.lastName];
}

Это просто очень простой пример. Может быть, ваше приложение управляет всей инвентаризацией группы складов. В этом случае вы, вероятно, захотите, чтобы классы представляли деталь, корзину, палитру, местоположение, поставщика, пункт назначения, заказ, счет-фактуру, вилочный погрузчик, оператора и т. Д. Когда кто-то выбирает деталь из корзины, вы хотите, чтобы эта корзина знала сколько деталей осталось и отправьте уведомление, если число меньше некоторого порога. Это уведомление может вызвать событие, которое заставляет погрузчик получить другую палитру такого рода детали и доставить ее в корзину. После того, как выбран, часть должна быть передана из корзины в заказ. Заказ, конечно, должен знать, как сгенерировать соответствующий счет. И так далее. Вся эта логика может быть частью модели.