10

我正在启动一个我认为会从绑定中受益的项目（我有一个源列表、几个浏览器视图等），但我认为如果没有它们，它也是非常可行的，也许更容易理解。根据我有限的经验，我发现绑定很难排除故障并且非常“神奇”（例如，很难在任何地方插入日志以找出东西在哪里破坏，一切要么正常，要么不正常）。

这只是我的缺乏经验（在这种情况下，我可以坐下来花一些时间来研究我对绑定的理解，并期望事情开始变得更清晰/更容易）还是我自己编写所有的胶水代码会更好我确信我可以理解和排除故障的方式。

4

7 回答 7

21

使用绑定。

请注意，您必须遵循 MVC 模式才能充分利用绑定。这比看起来要容易，因为如今 Cocoa 几乎为您做了所有事情：

  1. 查看：NSView和子类（当然），NSCell和子类，NSWindow和子类
  2. 控制器：NSController和子类（尤其是NSArrayController）
  3. 模型：核心数据

如果您不打算使用 Core Data，那么您可以滚动自己的模型对象，但这很容易。大多数这些对象的方法都是简单的访问器，只要@synthesize您以 Leopard 为目标就可以。

不编写任何代码通常无法摆脱困境，但绑定可以使您编写很少的代码。

推荐阅读：

于 2008-11-10T17:36:31.743 回答
8

绑定在本质上看起来很神奇。要了解绑定背后的魔力，我认为必须彻底了解 KVC/KVO。我真的是彻底的意思。

然而，就我而言（Obj-C 的新手——9 个月），一旦我获得了 KVC/KVO 绑定，我就感到很兴奋。它大大减少了我的胶水代码，让我的生活变得更加轻松。调试绑定成为确保我的键值更改是可观察的情况。我发现我可以花更多时间编写我的应用程序应该做的事情，而不是确保视图反映数据。

我确实同意，虽然绑定起初非常令人生畏。

于 2008-11-10T17:10:23.450 回答
5

我的一般方法是尽可能多地使用绑定开始，看看事情进展如何。然而，如果一个特定的界面元素在使用绑定时开始出现问题，或者付出的努力超出了它的价值，那么我会毫不犹豫地回退到使用更传统的方法（例如，数据源、操作）。我发现这些事情很难提前预测，但我认为从长远来看，支持绑定会更好，只要你在不提供绑定的情况下不要过于教条地坚持使用它们任何好处。

于 2008-11-10T18:18:17.073 回答
4

在使用 Bindings 一段时间后，我发现它根本不是魔法，认为它是足够先进的技术。调试绑定接口与胶合接口采用不同的技术，但一旦你掌握了这些技术，在重用、可维护性和一致性方面的优势就在 IMO 显着。

于 2008-11-10T19:05:02.017 回答
2

似乎我在我的应用程序中几乎同等地使用了绑定、KVO 和数据源方法。这真的取决于上下文。例如，在我的一个项目中，除了主窗口的大纲视图之外，我几乎在任何地方都使用了绑定，这非常复杂，以至于我什至不想尝试将其放入 NSTreeController 中。同时，我还使用 KVO 重新加载 UI 对象并跟踪模型对象中的依赖关系。

在学习 Bindings 或 Core Data 等高级 Cocoa 主题时要记住的重要一点是，您必须了解它们背​​后的所有技术；数据源协议、通知 KVO 等等。一旦你有足够的经验与他们一起工作来了解“魔法”是如何工作的，你就可以轻松地将更高级别的东西集成到你的应用程序中。

在您的特定情况下，您必须决定是否值得在开发应用程序的基础上花额外的时间来学习绑定。如果可能，使用绑定开发应用程序的简化原型可能对您有益，这样您就知道在开始实际项目时如何最好地将各个部分组合在一起。

于 2008-11-17T20:39:51.253 回答
2

我的意见是，是的，您应该采用绑定；该技术现在已被充分理解且稳定，并且对于您不再需要编写的大量代码而言，这是值得的。当我第一次切换到绑定时，我在让观察对象和被观察对象的生命周期匹配方面遇到了很多麻烦，并且 UI 损坏，因为它正在观察一个有效的对象，但它是不正确的对象。一旦你多次看到这些问题，知道如何避免它们以及如果它们确实出现如何发现它们就变得很简单了。伊什。我仍然希望在调试器中出现“这里的事件导致这里的更新”的痕迹，但我仍然很高兴我采取了行动。

于 2009-01-15T19:36:11.630 回答
1

出于好奇，我确实最终使用了绑定，几天后它们突然开始“有意义”。因此，我绝对建议您继续并花时间学习它们。

我还发现 Brian Webster 的建议很有帮助，因为我确实最终以老式的方式做了一些事情，要么是因为绑定不能做我想要的，要么是因为做我需要的事情会非常复杂。绑定。

于 2009-01-15T17:29:52.243 回答