1

我最近看到了很多关于这个特定模式的“猜测”和闲聊（因为我开始学习Dojo 工具包），但找不到任何关于这件事的明确信息。有人说，这是对频繁且“有害”（他们，而不是我）MVC 模式的解决方案。我列出了一些由 Interface-Compute 解决的 MVC“常见”大图问题。我找到了这个网站并阅读了它，但无法全面了解优缺点。

输入输出

视图组件被定义为一个静态组件，从不直接接受用户的输入。也就是说，对用户输入的反应是由与呈现用户刺激不同的组件处理的。但 GUI 编程环境并没有以这种方式在输入和输出组件之间划清界限：精心设计的 GUI 编程环境被组件化为用户界面功能的嵌套容器。

忽略浏览器

如果我们考虑声称支持构建所谓的“富互联网应用程序”的 Web 应用程序框架，那么整个框架都驻留在服务器上，因此，显然视图和控制器都是在服务器上实现的。这使得浏览器完全不在设计模型中。如果这是我们心中的设计图，那么浏览器的功能就只是一个具有良好输出功能的终端。

ETC...

我只是想知道所有 JavaScript 开发，如 Dojo Toolkit、Node.js 和其他一些用于光滑服务器端代码的开发（我认为我们可能会进入这种时代并重新思考我们使用 PHP 处理服务器端代码的方式、Java、Ruby on rails 等）。另外，能够在浏览器中调试服务器端和客户端代码真是太酷了！

4

1 回答 1

1

我快速阅读了您提供的链接，以了解您引用的上下文。我强烈地感觉到作者对 MVC 和面向对象知之甚少。

模型和视图是对象的集合/类别/域。每个对象都是完全自包含的，应该遵循 OO 原则。控制器提供视图对象方法来与模型对象交互（因为一般来说，一个动作会改变许多协作的模型对象，这可能很复杂）。

Interface-Compute提供的解决方案：

例如，如果检测鼠标点击是在一个单独的组件中实现的，而不是呈现按下或未按下按钮的组件，那么当鼠标点击按钮时，必须构造一些重要的机制来在两个组件之间进行通信。当鼠标输入识别和按钮呈现在同一个组件中实现时，这个问题就消失了。

实施 OO 原则有很多好处。似乎完全错过了。所以我只能说，如果他不想用对象编码，MVC 可能不适合。

于 2012-08-24T10:17:49.007 回答