iPhone MVC Вопрос о табличных представлениях и структурировании пользовательских моделей классов

Question

В эти дни я много читал о MVC и думаю, что думаю об этом, но я был бы признателен за некоторые советы и обоснованные мнения о том, как наилучшим образом решить мою проблему.

У меня есть 3 вопроса, действительно все связанные с шаблоном проектирования MVC.

1. Во многих примерах, с которыми я сталкивался, люди использовали контроллер (например, табличное представление) для заполнения массива объектами пользовательского класса (скажем, Student.h / m). Но не должен ли класс Student иметь вызываемые методы, которые возвращали бы массив данных для переменной в контроллере? Разве не так работает MVC? Что модель содержит определение данных и берет на себя ответственность за их чтение и запись?

2. Во многих примерах табличного представления в различных книгах, которые я читал, все они говорят: «Для удобства мы собираемся сделать контроллер нашим делегатом и источником данных для таблицы». Мне еще предстоит увидеть пример, когда табличное представление не использует контроллер в качестве источника данных. Как бы вы подключили табличное представление к другому источнику данных?

3. У меня есть 2 модели классов "Миссия" и "Аэродром". Каждому из них нужны данные из файла XML в облаке. Пишу ли я парсер в файлах реализации миссии / аэродрома? Создать отдельный объект Parser? Должны ли эти модели передавать данные на контроллер в виде массива?

Хотя я понимаю много теории, многие примеры, которые я нахожу в Интернете, похоже, нарушают многие концепции, которые, как я думал, я понял.

Любые объяснения приветствуются. Качество ответов на этом сайте просто потрясающее. Заранее спасибо

Answer 1

Вы, похоже, уже достаточно хорошо понимаете, как работает MVC, поэтому я просто добавлю несколько комментариев.

1. Контроллер отвечает за подачу данных в представление.Могут существовать миллионы различных состояний и сценариев, которые будут влиять на то, какие данные использовать и как, и это не задача модели выяснить это.Модель содержит данные, а контроллер обрабатывает логику.

2. Если вам нужен другой делегат или источник данных для вашего табличного представления, вы можете создать их экземпляр в контроллере табличного представления, изатем расскажите о них в табличном представлении, используя свойства delegate и dataSource.Им необходимо реализовать требуемые методы протоколов UITableViewDelegate и UITableViewDataSource.

3. Иногда модели и контроллеры пересекаются в функциональности, и это прекрасный пример такого случая.

   Одним из решений может быть предоставление классам mission и airfield наследования от пользовательского класса, который знает, как загрузить требуемый XML и настроить синтаксический анализатор, поэтому им просто нужно предоставить URL и переопределитьпарсеры обратного вызова для их конкретных тегов.Все остальное, что связано с загрузкой XML, может быть обработано в суперклассе.

   Другим способом может быть создание отдельного класса, который принимает URL и возвращает некоторый XML, а затем классы mission и airfieldвызовите этот метод и проанализируйте XML независимо.

   Неправильный способ - дать классам mission и airfield знать, как загружать и анализировать, потому что вам придется поддерживать код в обоих местах..

   Нормально иметь контроллер загрузки данных, который передает данные в контроллер представления, поэтому код контроллера может быть очень конкретным (и поддерживаемым).