这个问题主要针对Miguel作为MT.Dialog的创作者，但我也希望听到其他人的意见。 我目前正在重构一个有很多表视图的项目。我想知道我是否应该用MT.Dialog替换所有这些。
我的职业是：
缺点：
一般来说，只使用MT.Dialog或从中继承特定用例会更好吗？你有什么经历？
答案 0 :(得分：11)
解决您的一些问题。
MonoTouch.Dialog和UITableView之间的主要区别在于，使用前者“加载”您想要预先渲染的所有数据，然后忘记它。你让MonoTouch.Dialog负责渲染它，推送视图和处理部分/元素。使用UITableView，您需要提供回调方法，以返回节的数量，节的标题和数据本身。
UITableView的优势在于渲染一百万行具有相同的大小和相同的单元格，您不必提前加载所有数据，您可以等待回调。话虽如此，如果你使用不同高度的单元格，这会很快破裂，因为UITableView必须查询所有行的大小。
简而言之：
（1）是的，即使您使用自定义单元格，您也将受益于更短的代码和更简单的编程模型。无论您是否使用其他功能，都取决于您。
（2）对于性能，问题归结为您将拥有多少行。就像我之前提到的，如果你正在浏览一个可能很大的数据集，你必须预先在内存中加载所有这些单元格，或者像TweetStation一样，添加功能以“按需”加载。
实际情况是它会占用更多内存，因为您需要在MonoTouch.Dialog中加载数据。您最好的优化技术是让您的Elements非常轻巧。例如，Tweetstation使用“TweetElement”只保存推文的ID，并根据需要加载实际内容，以保持TweetElement在内存中的大小非常小。
使用UITableView，您无需支付该价格。但是如果你没有使用某种类型的数据库，那么数据仍然会在内存中。
如果您的应用程序要求数据在内存中，那么您也可以将数据移动为元素并将其用作模型。
（3）这有点像一个稻草人。您的数据“来源”永远不会真正独立于UIKit。我知道人们喜欢谈论这些模型是可重用的，但在实践中，你永远不能重用UITableViewSource作为除UITableView之外的任何东西。它的主要用途是支持不需要将数据预先加载到内存中的可伸缩控件，它实际上并不是将模型与View分离。
所以你真正拥有的是一个适配器类，它将UITableView的世界与你的实际数据模型（数据库，XML列表，内存数组，Redis连接）连接起来。
使用UITableView，您的适配器代码位于构造函数和UITableViewSource中。使用MonoTouch.Dialog，您的adatpro代码存在于将初始RootElement填充到DialogViewController的代码中。
所以有理由在MonoTouch.Dialog上使用UITableView，但它不是那三个缺点。
答案 1 :(得分：4)
我每次使用tableview时都会使用MonoTouch.Dialog（以及它的objc兄弟QuickDialog）。它有助于简化代码，并为您提供更好的表抽象。
但是有一个例外，那就是当表有数千行，数据在数据库中时。 MT.D / QD要求您预先加载所有数据，这样您就可以创建这些部分，如果您还没有内存中的对象，那就太慢了。
关于“打破MVC”，我有点同意你的看法。由于这个原因，我从未真正使用MT.D中的反射绑定。通常我最终会在代码中从头开始创建root，或者使用类似JSON（在我的fork https://github.com/escoz/MonoMobile.Forms中），这样我的域对象就不需要知道MT.D了。