2010-12-08 2 views
2

Что касается MVC, у меня есть UITableView, который создается в моем контроллере и объект модели, который действует как UITableViewDelegate & UITableViewDataSource. Когда я пришел к установке делегата и источник данных, я добавил и указать на модель:Где разместить UITableViewDelegate и DataSource в MVC?

// INSIDE CONTROLLER 
[tableView setDelegate:dataModel]; 
[tableView setDataSource:dataModel]; 

источник данных соответствует в модели, что чувствует себя хорошо. Но делегат, что лучше всего в модели (так это с DataSource), или будет (в условиях MVC) лучше в контроллере?

// INSIDE CONTROLLER 
[tableView setDelegate:self]; 
[tableView setDataSource:dataModel]; 

EDIT:я должен уточнить, что мои модели объектов содержит NSMutableArray, который содержит данные, я желаю, чтобы отобразить в UITableView (отсюда моя установка DataSource к модели). Это, похоже, работает хорошо, так как я могу заполнить UITableView непосредственно из модели.

ответ

3

Обычная практика, чтобы сделать ваш взгляд контроллера делегата и источник данных, имея его в соответствие UITableViewDelegate и UITableViewDataSource или иметь его как подкласс UITableViewController (который, вы заметите, соответствует самому этим протоколам). Конечно, код, который предоставляет вашему контроллеру фактические данные, должен оставаться в вашем слое модели.

В ответ на ваш EDIT ваш модельный класс может предоставить NSMutableArray в качестве свойства, к которому можно легко получить доступ с помощью контроллера представления вашей таблицы.

+0

Очень ценный GriffeyDog, именно то, что я был после, я буду перемещать «Контроллер» и «DataSource» в контроллер. Также в отношении редактирования у меня уже была настройка @property для массива и указатель на установку модели в моем контроллере, поэтому я должен получить доступ к массиву с контроллера. Спасибо. – fuzzygoat 2010-12-08 19:34:47

1

UITableViewDelegate несет ответственность за большее количество элементов, ориентированных на GUI, поэтому ваш контроллер представления, содержащий табличное представление, является лучшим кандидатом для представления делегата, источник данных не может быть связан с графическим интерфейсом, но обычно и во всех яблоках примеры они связывают контроллер, который содержит табличную как оба, так что в случае образцов яблока она выглядит (от контроллера табличных или IB): YourTableViewController.m

[self.tableView setDelegate:self]; 
[self.tableView setDataSource:self]; 
3

UITableViewDelegate документация Apple, кажется, описать делегат представления таблицы с точки зрения помощи в макете просмотра и т. п. К сожалению, на практике существует немного стыковки между ними: делегат, возвращающий динамическую высоту строки (даже если источник данных возвращает ячейки), или делегат, возвращающий заголовки разделов заголовка и нижнего колонтитула (хотя источник данных может просто возвращать равные названия).

Проблемы, подобные этому, затрудняют чистое разделение вида таблицы (что необходимо для вызова reloadData) из источника данных и источника данных из делегата. Когда это вообще возможно, это действительно проще, если тот же объект функционирует как источник данных и делегат. Когда это невозможно, делегат обычно имеет наибольший смысл в качестве контроллера представления, управляющего представлением представления таблицы.

Смежные вопросы