我有点困惑......简单地说...... MVC是如何完全面向对象的？
我知道从很多java和c＃开始，对象有状态和行为的OOP。
我发现我正在分离对象操作，并将它们全部放在我的控制器中，而不是将它们保存在一个实现中（与View一起是我最受诱惑的地方，但显然你不能这样做。）
例如，假设我有一个气球对象.. 它的模型保持其状态，如颜色，位置，在屏幕上移动的速度，移动方向等。 但是，如果我尝试执行任何操作，例如
-(void)moveBalloon:(CGPoint)destination
这在模型中通常是不可接受的，因为模型只保存有关对象的数据，而视图只绘制对象而无法知道其位置等。
也许我正在以一种奇怪的方式思考这个问题。我通常将BalloonView视为BalloonModel的独立对象，并将控制器视为自己的对象。
我的想法完全错了吗？
另外..在可重用性方面，如果我想将此对象提供给其他人在他们的应用程序中使用，我会给他们BalloonView和BalloonModel，但他们无法访问我所做的任何操作已经作为Balloon对象的一部分实现，因为它们位于控制器中。
答案 0 :(得分：3)
MVC就是将业务逻辑（模型）与用户界面（视图和控制器）分离开来。就其本身而言，MVC与面向对象（OO）编程几乎没有关系。您可以轻松编写遵循MVC设计策略的软件，而无需遵循OO策略。
程序的核心是其业务逻辑。在气球示例中，如果移动气球是您的程序需要执行的操作，则模型应该绝对具有moveBalloon:方法。换句话说，模型代码应该能够执行程序需要执行的所有操作。它应该存储程序状态，处理数据以及与软件内部工作相关的任何其他内容。视图应该是实际的UI元素（窗口，按钮，文本字段，图形等）。它们通常应该是“哑”（即没有内置的业务逻辑）。控制器应该处理UI的内部工作。
如果用户希望用鼠标移动那个气球，那么Controller和View通常会处理所有的点击，拖动和移动，而Model只会处理纯逻辑部分：气球。
答案 1 :(得分：2)
你是部分正确的。通过将气球分配到MVC部件，您无法轻松移交视图和模型以及控制器。不过，不用担心，你会发现，即使使用MVC，你仍然可以拥有可重复使用的气球。但是你需要一些改变观点。
您开发气球以在MVC应用程序中运行，就像您一样。给它一些setter和getter并称之为BalloonView。气球仅托管使用这些设置器提供给它的数据。
然后您决定运行气球所需的数据。可能是气球位置。创建BalloonModel并为其指定位置属性。在MVC应用程序中，数据可能存储在模型层中。气球的另一个用户（另一个应用程序）可以将数据存储在主类中，甚至可以在设置对象时设置静态数据。由用户决定他/她如何处理气球数据。
控制器然后将气球与应用程序连接。可能有一个触发控制器的按钮。控制器访问BalloonModel，使用新位置对其进行更新。然后必须以某种方式将BalloonModel更改传播到BalloonView。如何实现这一目标有不同的技术。 MVC框架通常期望模型调度事件和视图调解器来连接此事件和特定视图。所以视图不需要知道它的模型。但它可能会这样做。在我们的示例中，模型将调度UPDATE事件，mediatator将接收该事件并更新视图的位置属性。 另一个用户（应用程序）可以通过直接连接按钮与气球定位完全省略控制器：
onclick: balloonView.x += 5;
你知道，即使你没有移交模型和控制器，你的balloonView仍然可以重复使用。
-
MVC对于具有相当大的应用程序有意义。简单的应用程序不需要遵循MVC。这将是矫枉过正的。较大的应用程序需要一些高级结构来轻松定位职责，例如：数据来自何处，允许哪些操作以及在何处可以找到它们。
UI组件开发人员通常仅为特定组件创建迷你MVC架构。模型，视图和控制器然后在同一目录中，可以编译成二进制文件（my_super_list_component.binary）并在其他项目中重用。
答案 2 :(得分：2)
MVC和OOP：
MVC应用程序的不同部分通过事件（或信号或消息）进行通信。演员（视图，模型或控制器）可以调度此类事件，而另一个演员则侦听该事件。这不是OOP，因为一个对象知道另一个对象并通过定义的接口调用方法，这让你很担心。
然而，使用MVC甚至鼓励更好的OOP设计！然后让我们让你的所有对象自己托管他们的数据和动作。你需要什么联系让他们一起玩。 MVC使您可以限制对象之间的必要连接。这是OOP原则之一。 MVC的另一个特性是封装整个应用程序职责。不使用MVC要求您的应用程序逻辑分布在整个代码中，这不是OOP建议的。 MVC允许您封装应用程序的不同部分，因此是应用程序宏级别的OOP。并且 - 我们遵循OOP原则 - 您可以轻松地更改控制器或模型或视图并使其可重用和可扩展：D