我有一个实体，它代表一个Person 和一个UITableViewCell 子类，它显示了该人的一些属性。
问题是：您通常在哪里配置（设置文本、图片等）表格单元格？你：
A) 在实现tableView:cellForRowAtIndexPath: 的同时在UITableViewController 子类中配置它？
B) 将Person对象传入UITableViewCell子类，让子类自行配置？
C) 完全不同的东西？
如果你的回答是选项 A，那么这个呢？
假设对于表格视图中的第一行，我需要将所有标签的文本加粗。这会改变你的看法吗？你看我在这里得到什么，如果你在视图控制器中配置单元格，视图控制器将变得臃肿，其中包含它 真正 不需要的信息。但是，如果将所有配置都放在表格单元子类中，则会失去一些可重用性。这绝对是一种权衡，但我想知道大多数工程师会选择什么。
【问题讨论】：
标签： objective-c ios cocoa-touch uitableview
转到您的界面构建器并选择单元格。使用检查器，将您的单元格与您的自定义 UITableViewCell 链接。
之后，在tableView:cellForRowAtIndexPath: 而不是UITableViewCell 上实例化您的单元格，配置它并瞧瞧。
然后，回答您的评论：
将单元格项目链接到自定义单元格标题中的属性。
假设我在本例中创建了属性UILabel cellTitle，所以当我在tableView:cellForRowAtIndexPath: 处实例化单元格时，我只需设置该属性的文本即可。
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = @"pedidosCell"; //the same at the nib!
CustomTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
// Configure the cell...
cell.cellTitle.text = @"This is my cell title";
// Using your Person object, that should be available here.
cell.cellTitle.text = [Person name];
return cell;
}
至于粗体，您应该坚持使用选项 A。在 UITableViewCell 中加载数据是一项不常见的任务，因为它应该非常快地处理滚动。将数据放入其中不会像 Apple 预期的那样工作。
当然，您可以通过将indexPath.row 传递给单元格来让单元格知道其位置，然后在需要时将文本设置为粗体。我不知道这将如何与dequeueReusableCellWithIdentifier:一起玩
【讨论】：
person 对象传递给DataSourceDelegate，因为单元格应该不知道它的数据。
我通常的做法是 A) 和 B) 的组合...
我使用类别将value 属性添加到UITableViewCell。然后我创建一个或多个 UITableViewCell 的子类，为我想要显示的每种类型的行/值创建一个。
在我的数据源的tableView:cellForRowAtIndexPath: 方法中，我将相应子类的单元格出列/分配，并将value 设置为要为该行显示的值。
也许其他人可以帮助使用UITableViewController--我个人认为它不是很有用。我通常只是为我正在显示的每种类型的视图创建子类 UIViewController。如果该视图包含一个表格视图，我给我的视图控制器一个 tableView 出口。这类似于为我需要的每种类型的单元格子类化 UITableViewCell。
【讨论】：
value 时，每个单元子类都会适当地配置自己。不确定您所说的“接口中包含的实际数据结构”是什么意思。如果您的意思是我认为的意思，这意味着您的数据源代码可以是通用的（cell.value = valueForRow），而无需为不同类型的值编写特殊情况。这很容易编写和维护。
我已经开始做 B 了（它看起来如此不可抗拒），我还没有遇到过问题。
我是怎么做到的，细胞子类对模型对象有一个弱引用。 Controller 为其提供引用，并配置其属性以在 setRefence: 方法中显示。
单元子类将仅用于显示模型项。这意味着我的控制器代码既漂亮又干净（我的意思是小而简单），这意味着单元变体很容易制作和插入，实际上您可以开始进一步概括它并使用只需添加的子类控制您的显示器所需的配置差异。一个有趣的应用程序有多个表格，每个表格都有特定的单元格，代码会少得多——可以使用通用控制器，单元格子类和模型包含它们的细节。
我还没有看到缺点。
“但是，如果您想在另一个项目中重用该类怎么办？” - 我会重用模式，而不是代码。
“但是您将显示对象与其显示的数据紧密耦合” - 那又如何？它们协同工作——控制器建立关系并协调它们——这就是它的用途。让您的视图引用他们的模型。
（我在这里发帖是因为我想知道如果这种方法是错误的（并且我已经看到它被列为一种罪过）那么为什么它是错误的？）。
【讨论】：
“配置”是什么意思？您是说将 Person 的数据添加到单元格中吗？我会在cellForRowAtIndexPath: 中执行此操作，这通常是视图控制器的一部分（通常将表视图的委托设置为视图控制器）。理想情况下，Person 的数据是应用程序中某个模型的一部分。您可以使用索引路径获取单元格的 Person，例如
Person *personForThisCell = [SomeModel getPersonAtIndex: [indexPath row]];
然后使用该数据设置单元格的值。
【讨论】：