问题MVC在于人们认为视图，控制器和模型必须彼此尽可能独立。他们不是-视图和控制器经常交织-认为是M(VC)。
控制器是用户界面的输入机制，通常在视图中比较复杂，尤其是对于GUI。不过，视图是输出，而控制器是输入。视图通常可以在没有相应控制器的情况下工作，但是没有视图的控制器通常远没有那么有用。用户友好的控制器使用该视图以更有意义，更直观的方式解释用户的输入。因此，很难将控制器概念与视图区分开。
可以将密封盒中检测场上的无线电遥控机器人视为模型。
该模型只涉及状态和状态转换，没有输出（显示）或触发状态转换的概念。我可以在现场获得机器人的位置，并且机器人知道如何转换位置（向前/向后/向左/向右迈出一步。很容易在没有视图或控制器的情况下进行构想，但无济于事
考虑一个没有控制器的视图，例如，网络中另一个房间中的某个人在另一个房间中观察机器人位置，因为（x，y）坐标沿滚动控制台向下流。该视图仅显示模型的状态，但此人没有控制器。同样，无需控制器即可轻松实现此视图。
考虑一个没有视线的控制器，例如有人将壁橱锁在壁橱中，而无线电控制器已调整到机器人的频率。该控制器正在发送输入，并导致状态转换，但不知道它们对模型做了什么（如果有的话）。易于设想，但没有视图的某种反馈就没有真正的用处。
大多数用户友好的UI都会与控制器协调视图，以提供更直观的用户界面。例如，想象一下带有触摸屏的视图/控制器，该视图/控制器以二维方式显示机器人的当前位置，并允许用户触摸屏幕上恰好在机器人前面的点。控制器需要有关视图的详细信息，例如视口的位置和比例，以及相对于机器人在屏幕上的像素位置所触摸的点的像素位置），以正确地进行解释（与锁定在壁橱中的家伙不同）无线电控制器）。
我已经回答你的问题了吗？:-)
控制器是从用户那里获取用于使模型转换状态的输入的任何东西。尝试使视图和控制器保持分离，但要意识到它们通常是相互依赖的，因此，如果它们之间的边界模糊，也可以，例如，将视图和控制器作为单独的程序包可能不会像您将其分离得那么干净一样喜欢，但这没关系。您可能不得不接受不会将控制器与视图完全分开，因为视图与模型是一样的。
...应该在控制器中进行任何验证等吗？如果是这样，我如何将错误消息反馈回视图-应该再次通过模型，还是控制器应将其直接发送回视图？
如果验证是在View中完成的，那么我应该在Controller中输入什么？
我说链接的视图和控制器应该自由交互，而无需遍历模型。控制器接受用户的输入并应进行验证（也许使用模型和/或视图中的信息），但是如果验证失败，则控制器应能够直接更新其相关视图（例如，错误消息）。
为此，要进行严格的测试，以问问自己是否由于他人的验证错误（例如，壁橱中的那个人）而使独立视图（即，另一个房间中的那个人通过网络监视机器人的位置）是否应该看到任何东西。试图告诉机器人下地步）。通常，答案是否定的-验证错误阻止了状态转换。如果没有状态转变（机器人没有移动），则无需告诉其他视图。壁橱里的那个家伙只是没有得到任何试图导致非法转换的反馈（没有视图-用户界面不好），其他人也不需要知道。
如果带有触摸屏的人试图将机器人从现场送出，他会收到一条友好的用户友好消息，要求他不要通过将其从检测场上送出而杀死机器人，但是同样，没有其他人需要知道这一点。
如果其他视图确实需要了解这些错误，那么您实际上是在说用户的输入和任何由此产生的错误是该模型的一部分，整个过程要稍微复杂一点……