MVC 和 cocoa 绑定最佳实践问题
假设我有一个视图 myView、一个视图控制器 myViewController 和某种模型对象 myModel。 此外，假设模型有两个符合 KVO 的属性，arrayOfPeopleNames 和 arrayOfAnimalKinds（均为 NSString）。
在我看来，我希望有两个弹出窗口绑定到这两个数组的内容。
我的问题是，如果 myController 引用了 myModel，并且下拉列表绑定到 myViewController，那么按照 myModel.arrayOfPeopleNames 的方式设置键路径是否是一个好习惯？
或者我是否需要在 myViewController 中设置一个额外的 NSArray 来镜像 myModel 中的 NSArray 并绑定到该键路径？
从实现的角度来看，前者似乎要简单得多（我不必使控制器数组镜像模型数组），但我想知道它是否将模型暴露给视图。
意见？
Lets say I have a view, myView, a view controller, myViewController, and some sort of model object, myModel. Further, lets say the model has two KVO compliant properties, arrayOfPeopleNames and arrayOfAnimalKinds (both NSStrings).
In my view I want to have two pop-ups bound to the contents of these two arrays.
My question is, if myController has a reference to myModel, and the dropdown is bound to myViewController is it good practice to set a keypath along the lines of myModel.arrayOfPeopleNames?
Or do I need to set up an additional NSArray in myViewController which mirrors the one in myModel and bind to that keypath instead?
The former seems a lot simpler from an implementation point of view (I don't have to make the controller array mirror the model array), but I'm wondering about whether it exposes the model to much to the view.
Opinions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不应该在控制器中镜像模型的数组。 虽然在非常简单的情况下我不会太关心直接绑定到模型的数组，但您也可以将 UI 对象绑定到管理模型数组的 NSArrayController。 这将提供模型和 UI 之间的分离，更重要的是处理排序、选择、添加和删除对象等任务。
我可以通过担心 KVO 和绑定违反“纯”模型视图控制器设计来了解您的出发点，但这不是您应该担心的事情。 即使 KVO 通知直接从模型传递到视图，设置和更改视图和模型之间的连接仍然是控制器的责任（仅在这种情况下，它是通过 IB 完成的）。 例如，您不希望模型对象获取对视图的引用，并将其自身绑定到 UI，这将是控制器的责任。
作为要避免的另一个例子，请考虑您的模型是否有一组“动物 ID”而不是名称。 您可能不想创建将动物 ID 转换为模型中人类可读的动物名称的方法，而是希望创建一个值转换器或格式化程序来进行转换。 这使您可以保持模型和视图之间的分离级别。
还要记住，设计模式的目的是降低问题解决方案编码的复杂性，而不是增加复杂性。 您将看到这正是 Cocoa 的工作方式，尽管它可能并不总是遵循最严格的模式定义。
You shouldn't mirror the model's array in the controller. Although I wouldn't be too concerned about binding directly to the model's array in a very simple case, you could also bind your UI objects to an NSArrayController, which manages the model's array. This would provide separation between the model and UI, and more importantly handle tasks like sorting, selection, adding and removing objects, and so on.
I can see where you're coming from by being concerned KVO and bindings violates "pure" model view controller design, but it's not something you should worry about. Even though the KVO notifications pass directly to the view from the model, setting up and changing the connection between the view and model is still the responsibility of the controller (only in this case it's done through IB instead). For instance, you wouldn't want a model object to get a reference to the view, and bind itself to the UI, that would be the controller's responsibility.
As another example of something to avoid, consider if instead your model had an array of "animal IDs" instead of names. Instead of creating a method to translate animal IDs to human readable animal names in the model, you might instead want to create a value transformer or formatter to do the conversion. This allows you to maintain that level of separation between the model and view.
Keep in mind also that the purpose of design patterns is to reduce the complexity of coding a solution to a problem, never to increase it. You'll see that this is exactly the way Cocoa works, even though it might not always adhere to the strictest definition of a pattern.