Является ли Monotouch.Dialog подходящей заменой для всех UITableviews?

Чтобы ответить на некоторые ваши вопросы.

Основное различие между MonoTouch.Dialog и UITableView заключается в том, что с первым вы «загружаете» все данные, которые хотите отобразить заранее, а затем забываете об этом. Вы позволяете MonoTouch.Dialog позаботиться о его рендеринге, отправке представлений и заботе о разделах/элементах. С UITableView вам необходимо предоставить методы обратного вызова для возврата количества разделов, заголовков для разделов и самих данных.

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

Итак, вкратце:

(1) да, даже если вы используете пользовательские ячейки, вы выиграете от более короткого кода и более простой модели программирования. Воспользуетесь ли вы другими его функциями или нет, решать вам.

(2) Для производительности проблема сводится к тому, сколько строк у вас будет. Как я упоминал ранее, если вы просматриваете потенциально большой набор данных, вам придется загружать все эти ячейки в память заранее или, как в случае с TweetStation, добавлять функции для загрузки «по запросу».

Реальность такова, что это будет потреблять больше памяти, потому что вам нужно загрузить свои данные в MonoTouch.Dialog. Ваш лучший метод оптимизации — сделать ваши элементы очень легкими. Tweetstation, например, использует «TweetElement», который просто содержит идентификатор твита и загружает фактическое содержимое по запросу, чтобы размер TweetElement в памяти оставался очень маленьким.

С UITableView вы не платите за эту цену. Но если вы не используете какую-либо базу данных, данные все равно будут в памяти.

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

(3) Это немного соломенный человек. Ваш «источник» данных никогда не будет независимым от UIKit. Я знаю, что людям нравится говорить об этих моделях как о повторно используемых, но на практике вы никогда не сможете повторно использовать UITableViewSource в качестве источника для чего-либо, кроме UITableView. Его основное использование заключается в поддержке масштабируемых элементов управления, которые не требуют предварительной загрузки данных в память, на самом деле речь не идет об отделении модели от представления.

Итак, у вас действительно есть класс адаптера, который соединяет мир UITableView с вашей фактической моделью данных (база данных, список XML, массив в памяти, соединение Redis).

С UITableView код вашего адаптера находится в конструкторе и UITableViewSource. С MonoTouch.Dialog ваш код adatpro живет в коде, который заполняет начальный RootElement для DialogViewController.

Таким образом, есть причины использовать UITableView вместо MonoTouch.Dialog, но это не один из этих трех недостатков.

Я использую MonoTouch.Dialog (и его брата QuickDialog для objc) практически каждый раз, когда я использую табличное представление. Это очень помогает упростить код и дает вам лучшую абстракцию таблицы.

Однако есть одно исключение, когда таблица будет иметь тысячи и тысячи строк, а данные находятся в базе данных. MT.D/QD требует, чтобы вы загрузили все данные заранее, чтобы вы могли создавать разделы, и это просто слишком медленно, если у вас еще нет объектов в памяти.

Что касается «взлома MVC», я с вами согласен. Из-за этого я никогда не использую привязки отражения в MT.D. Обычно я создаю корень с нуля в коде или использую что-то вроде JSON (в моем форке https://github.com/escoz/MonoMobile.Forms), чтобы объектам моего домена не нужно было знать о MT.D.