model-view-controller - 嵌套 MVC 通信模式

Question

这完全是一个最佳实践类型的问题，因此语言无关紧要。我了解 MVC 的基本原理，并且它有不同的、微妙的风格(即直接引用模型的 View 与来自 Controller 的数据委托(delegate))。

我的问题是关于跨 MVC 通信，当这些 MVC 嵌套时。这方面的一个例子是绘图程序(如 Paint 或其他东西)。 Canvas 本身可以是 MVC，但每个绘制的实体(例如 Shapes、Text)也可以。从模型的角度来看，CanvasModel 是有意义的。拥有实体集合，但 CanvasView和 CanvasController分别有相应的实体 View 和 Controller 集合吗？

另外，添加新绘制实体的最佳/最干净的方法是什么？假设用户激活了 CircleTool，他们在 Canvas View 中单击并开始绘制形状。 CanvasView可以触发 CanvasController 的相关鼠标向下/移动/向上事件可以听。然后 Controller 基本上可以将这些事件代理到 CircleTool(状态模式)。在鼠标按下时，CircleTool 会想要创建一个新的 Circle。该工具是否应该创建一个新的 CircleEntityController直接调用 canvasController.addEntity(circleController) ?那么创建 Circle 的模型和 View 的责任应该在哪里呢？

对不起，如果这些问题有些模糊:)

-- 编辑 --

这是我正在谈论的伪代码示例:

CircleTool {
    ...
    onCanvasMouseDown: function(x, y) {
        // should this tool/service create the new entity's model, view, and controller?
        var model = new CircleModel(x, y);
        var view = new CircleView(model);
        var controller = new CircleController(model, view);

        // should the canvasController's add method take in all 3 components
        // and then add them to their respective endpoints?
        this.canvasController.addEntity(model, view, controller);
    }
    ...
}


CanvasController {
    ...
    addEntity: function(model, view, controller) {
        // this doesn't really feel right...
        this.entityControllers.add(controller);
        this.model.addEntityModel(model);
        this.view.addEntityView(view);
    }
    ...
}

Answer 1

哇，好吧，我可能对这个问题有一个令人惊讶的答案:我一直在提示 MVC 如何被认为是编程中完美的象征，没有人认为有任何问题。最喜欢的面试问题是“您在 MVC 中可能会遇到哪些问题或挑战？”令人惊讶的是，这个问题经常以一种困惑、不安的表情迎接。

答案非常简单:MVC 依赖于多个消费者从单个共享模型对象满足其需求的概念。当各种观点提出不同的要求时，事情就真的开始走向 hell 了。几年前有一篇文章，作者提出了分层 MVC 的概念。其他人在评论中出现并告诉他们他们认为他们发明的东西已经存在:一种称为 Presentation-Abstraction-Controller (PAC) 的模式。您在模式文献中看到这一点的唯一地方可能是 Buschmann 的书，有时被称为五人帮，或 POSA(面向模式的软件架构)。有趣的是，每当我解释 PAC 时，我都会使用绘画程序作为完美的例子。

主要区别在于，在 PAC 中，表示元素往往有自己的模型，这就是 PAC 的 A:对于每个组件，您不必有，但可以有一个抽象。根据此处的其他一些响应，然后发生的是您有一个协调 Controller ，在这种情况下，它将统治 Canvas 。假设我们想在 Canvas 的一侧添加一个小 View ，显示各种形状的数量(例如正方形 3、圆形 5 等)。该 Controller 将向协调 Controller 注册以监听两个事件:elementAdded 和 elementRemoved。当它收到每个通知时，它会简单地更新它在自己的抽象中的映射。想象一下，改变一堆组件用来添加对此类事物的支持的共享模型将是多么荒谬。此外，制作 ShapesSummary 组件的人不需要学习任何东西，但事件协议(protocol)，当然，它与协作者的所有交互都是不可变的。

分层部分是 PAC 中可以有多个 Controller 层:例如，Canvas 级别的协调 Controller 不会知 Prop 有特殊行为的各种组件中的任何一个。我们可能会创建一个可以包含其他东西的形状，这需要逻辑来接受拖动等。该组件将具有自己的抽象和 Controller ，并且该 Controller 将与 CanvasController 协调其事件等。它甚至可能在它与它所包含的组件进行通信的某个点。

这是POSA Book .