1

这个问题是针对 iOS 开发的。

想象一下，您使用UITableView并在UITableViewCells其中通过我们将调用的更复杂的类显示有关您的一个或多个应用程序业务对象的信息ComplexBOView。

现在您想在用户点击包含在您的视图中的这个视图时触发一个特定的动作UITableCellView（该事件可以通过 a 触发UITapGestureRecognizer）

大多数时候，被认为是“最佳实践”的是使用 的tag属性UIView来实际返回您的模型并检索正确的业务对象。

这通常是合适的，但在某些情况下，保存指向用于构建您的ComplexBOView.

@interface ComplexBOView : UIView
{
    UILabel* lblSummary;
    // ....

    UITapGestureRecognizer* tapGesture;
    NSObject* businessObject_;
}

@property (nonatomic, readonly) UITapGestureRecognizer* tapGesture;
@property (nonatomic, assign) NSObject* businessObject;

这背后的想法是，当用户点击视图时，实际上直接返回到 businessObject。

这里有两个问题

  • 在 UIView 中有 NSObject* 信息真的很糟糕吗？
  • 是否应该保留此信息，这意味着视图和模型之间的关系在这里变得更加牢固（视图对对象的所有权）？

谢谢你的建议。

4

3 回答 3

1

你应该坚持委托设计。您永远不知道何时可能需要代码方面的帮助，而人们希望使用委托。在我看来，这会使你的代码变得意大利面。

请记住，视图会被回收，尤其是在表格视图中。一旦视图看不见，它就会被重新使用，所以你放在那里的任何逻辑至少可以说维护起来很复杂

于 2012-11-08T11:38:19.680 回答
1

Trausti Thor 是对的。一旦你开始这种捷径，那就是一千次妥协的死亡（或者换句话说，技术债务只会堆积起来，直到它产生的代码库如此可怕，没有人愿意碰它，以防万一他们打破别的东西）。

每当您有机会做对时，第一次就做，因为有时商业或其他压力会迫使您不这样做，这些是不可避免的，但您希望通过做出妥协来尽量减少此类妥协的影响例外。

最后，如果它是一个例外，几乎是你代码上的一个污点，你可能会更倾向于在更安静的时间返回并修复它。

于 2012-11-08T11:48:07.387 回答
1

一般建议是

视图不拥有数据！

这是一个很好的建议。从长远来看，它可以为您省去很多麻烦。但是自己是什么意思？如果您查看 aUIButton或 a UILabel，则该按钮具有title标签 atext属性。所以他们持有一些数据，他们必须 - 替代方案必须有一个代表，每次绘制时都被要求提供文本。

那么在你的情况下这意味着什么？那要看情况了。如果您ComplexBOView只是专门设计用于显示您的特定业务对象的通用视图，那么将该对象保存在它的属性中并不是最糟糕的（只是我的观点）。

当然，您失去了使用不同模型轻松重用该视图的可能性，但也许无论如何这不是一个选择，因为它是如此具体。当然，您可以将所有代码从ComplexBOView控制器移至控制器。但是正如您所说，您还必须在每个模型对象和适当的视图之间保持连接。（顺便说一句。我不会使用tag来做到这一点，最好只使用 `NSDictionary 代替）

另一方面，特劳西和迈克尔确实有有效的观点。如果你这一次打破了这个“规则”，你可能会在其他任何场合都松懈并打破它，在你意识到之前，你最终会得到很多自定义视图，每个视图都包含对模型某些部分的引用。从长远来看，您可能会对模型进行更改（可能以您一开始没想到的方式进行更改 - 相信我，这会经常发生）然后您必须去每个子类并调整它们. 当然，如果特定于模型的代码存在于您的控制器中，您还必须修改所有这些，但至少它们都在一个地方。

总而言之，这些最佳实践、建议和设计模式的存在是有充分理由的。它们在无数情况下证明自己是有用的。所以总的来说，你只要跟着他们就行了。然而，在某些情况下可能值得违反它们，但您必须有一些非常好的理由，并且您应该意识到后果。

归根结底，这是你的代码、你的设计、你的决定。也许你猜错了，但有些教训必须通过艰难的方式学习。下次你知道该怎么做，更重要的是，为什么。创造自己的经验总是很有价值的。

于 2012-11-08T12:32:16.040 回答