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