讨论iPhone上的MVC实现 [英] Discuss on MVC implementation on iPhone

查看:141
本文介绍了讨论iPhone上的MVC实现的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是在不同的框架上使用MVC模式一段时间,例如(swing,android,gwt ...)
现在,我正在学习iPhone框架,我对MVC实现感到非常惊讶。我问的问题是关于视图和控制器的交互。

Im a using the MVC pattern for a while on different frameworks such as (swing, android, gwt ...) Now, I'm learning the iPhone framework and I am quite surprised about MVC implementation. The questions I am asking are about the view and controller interaction.

首先,这就是我设想MVC模式的方式:

First of all, that's the way I conceive the MVC pattern :


  • 视图和控制器通过接口相互通信(一个用于视图,另一个用于控制器)

  • The view and the controller communicate each other through an interface (one for the view and an other one for the controller)

在我对MVC模式的概念中,控制器不必知道视图的属性。 (例如,控制器不能拥有视图的标签属性实例,但可以通过视图界面的方法让视图更改此标签的值)

In my conception of the MVC pattern, the controller do not have to know the attribute of the view. (for instance, the controller can't have a label attribute instance of the view but can ask the view to change the value of this label via a method of the view interface)

不让控制器直接在视图UI元素上工作的优点是耦合度低,因此可以更容易地测试视图。可以在隔离(或使用模拟控制器)上启动和测试视图。

The advantage of not letting the controller directly work on view UI elements is a low coupling and therefore it is possible to test the view easier. The view can be launched and tested on isolation ( or with a mock controller ).

关键是,在iPhone上控制器(例如ViewController)直接知道UI元素因此我不理解。
我的目标不是批评我刚刚学习的框架。但是,如果这真的像我描述的那样工作,我发现它并不干净......

The point is, on iPhone the controllers (ViewController for instance) know directly the UI elements hence my incomprehension. My goal is not to criticise a framework I'm just learning. But if this is really working as I described it, I don't find that really clean...

有没有人对这个框架进行更多实验,谁可以给我详细信息/解释?或者如果你对我的MVC方法有不同意见,请告诉我;)

Is there anybody more experimented with this framework who can give me details / explication ? Or if you feel disagree with my MVC approach, tell me ;)

更重要的是,我问我的方法是不是MVP的近似(这里描述: http://code.google.com/intl/fr/webtoolkit/articles/testing_methodologies_using_gwt。 html )比MVC。

What's more, I am asking if my approach is not neareast to MVP (described here : http://code.google.com/intl/fr/webtoolkit/articles/testing_methodologies_using_gwt.html) than MVC.

推荐答案

MVC意味着不同的东西,因为它是首先在Smalltalk中正式化,而NeXTSTEP(Cocoa)版本的MVC则没有与Smalltalk完全匹配。 Smalltalk的分解基本上是这样的:

MVC has meant different things since it was first formalized in Smalltalk, and the NeXTSTEP (Cocoa) version of MVC doesn't exactly match up with Smalltalk's. Smalltalk's break-down is basically like this:


  • 模型保存数据

  • 视图显示数据

  • Controller管理用户交互

NeXTSTEP的分解实际上更像是这样:

NeXTSTEP's break-down is in practice more like this:


  • 模型保存数据

  • 视图绘制数据

  • Controller管理逻辑(包括绘图数据的演示部分)

我在这里区分在绘图和呈现之间,NSView往往对数据的含义感到愚蠢。它只专注于绘制像素。所以你倾向于传递它的实际字符串,而不是视图撕裂和呈现的对象。

I'm differentiating here between drawing and presenting in that NSView tends to be dumb about the "meaning" of the data. It just focuses on drawing pixels. So you tend to pass it actual strings rather than an object that the view tears apart and "presents."

这不是一个巨大的差异,但它是事物的原因就像你遇到的那样。 IMO的主要转变是,通过Cocoa / NeXTSTEP,视图类变得越来越可重用。在变得如此可重复使用时,更多应用敏感部分需要移出控制器。我相信这通常是一个好处,因为它导致更少的子类,更易理解的代码和更多可重用的代码......大多数时候。特别是,它允许您更轻松地交换进行更高级绘图的视图(以特定方式设置动画或在行等上交替颜色的视图),而不会碰到通常位于控制器中的任何特定于应用程序的逻辑。

It's not a huge difference, but it is the cause of things like what you're running into. The main shift IMO, is that with Cocoa/NeXTSTEP, the view classes have become more and more reusable. In becoming so reusable, more of the application-sensitive portions have needed to move out into the controller. This I believe is generally a benefit because it leads to fewer subclassses, more understandable code and more reusable code... most of the time. In particular, it allows you to more easily swap in views that do fancier drawing (a view that animates a particular way or alternates colors on rows or the like) without bumping into any application-specific logic which generally lives in the controllers.

这就是说,当一个视图特别复杂时,我发现创建更专业的视图来获取数据对象并管理他们自己的演示文稿是有益的,更多的是我认为的方式你正在想象。

That said, when a view is particularly complex, I do find it beneficial to create more specialized views that take a data object and manage their own presentation, more in the way I believe you are envisioning.

编辑:还有一点需要注意。 Apple的示例代码在设计方面通常很糟糕。它们几乎从不包含模型类,并且几乎可以将所有可以想象的东西塞进ViewControllers中,更糟糕的是:AppController(在我看来应该是一个非常简单的对象)。这通常是因为他们的示例代码试图展示某些特定点,并且他们不想包含破坏事物的复杂性(或者作者是懒惰的;请选择)。因此,虽然我确实认为智能视图控制器通常运行良好,但您不应将示例代码作为示例。遗憾的是,由于大多数Cocoa应用程序都是封闭源代码,因此没有很多典型的应用程序级别Cocoa设计实例。一个很好的例子是 Adium 。这是一个大型,精心设计的多开发人员Cocoa应用程序的绝佳示例。

One additional thing to note. Apple's example code often is terrible in terms of design. They almost never include model classes at all, and cram almost everything imaginable into the ViewControllers and worse: the AppController (which should be a very simple object in my opinion). This is generally because their sample code is trying to demonstrate some specific point and they don't want to include the complexity of breaking things up (or the author is being lazy; take your pick). So while I do believe that smart view controllers often work out well, you shouldn't take the example code as a demonstration of this. Unfortunately, there aren't a lot of canonical examples out there of good application-level Cocoa design, since most Cocoa apps are closed source. One good example to learn from is Adium. It is an excellent example of a large, well-designed, multi-developer Cocoa app.

这篇关于讨论iPhone上的MVC实现的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆