MVC 设计 - 有多少个控制器？

Question

概述

我正在构建一个简单的 Web 应用程序，由画布和画布上的元素组成。

画布支持以下操作：加载、保存

元素支持以下操作：移动、调整大小

网页上的 JavaScript 会针对每个操作向服务器发送一条消息，然后服务器发送相应的响应。

我的设计

注意：Canvas 和 Element 对象之间的箭头应该是表示 Canvas 对象包含 Element 对象的列表。我没有正确的图表符号。

示例工作流程

1. 画布上的元素被移动，生成 element_moved 消息。
2. 前端控制器管理会话并将消息传递到具有正确画布对象的画布控制器。
3. 画布控制器检查该消息并发现它适用于画布上的元素，并将其传递给元素控制器。
4. 元素控制器解析消息并直接更新适当的元素对象。

问题

这种控制器的分层排列在 MVC 设计中是否常见，还是我完全没有抓住要点？我已经搜索了几个小时，但没有找到任何比简单返回页面视图更深入地讨论 MVC 设计的网站。

我设计背后的动机是，客户端需要与之交互的每个对象都有一个控制器，这样，如果界面发生变化（以支持新方法），则可以更新相应的控制器，而不会影响设计的其他部分。

Answer 1

通常，在 MVC 中不会有一个控制器调用另一个控制器。您指定的元素控制器实际上只是更新画布模型的业务逻辑的一部分。如果您的用例要求您独立于 Canvas 更新元素，那么您将有一个单独的元素控制器，调用业务逻辑来更新元素。

干杯，
瑞安

Answer 2

在尝试组织 MVC 的客户端 JavaScript 中的问题时，您的情况引发了基本问题。

---

第一个基本问题

1) 是否应该整个“页面”使用一个整体Controller，其中此类Controller的成员方法是处理单个Model和单个模型的事件处理程序/起点code>View 整个页面？

用正则表达式来说...

Controller{1}

Model{1}

View{1}

由于只有一个Controller，因此其方法必须充当输入的事件处理程序/侦听器的想法没有歧义方案：Controller.moveCircle()。

装傻一分钟，如果只有一个 Model，那么您可以简单地去一个地方创建您需要的所有数据/状态处理方法。正确的？ (呵呵);-) Model.calculatePosition(), Model.calculatePrice()

在最基本的客户端/Web场景中，如果只有一个View，人们可能认为只需将所有表示逻辑放在那里就可以完成工作：View.repositionCircle(x, y)、View.repositionTriangle(x, y)< /code>

讨论 1

为什么像这样的整体 Controller、Model 或 View 方案在未来？

我可以将各个屏幕元素及其行为转移到其他“页面”，而不会有任何麻烦或额外的负担吗？

耦合和内聚

考虑耦合。整体控制器是否松散或紧密耦合访问屏幕目标？

想想凝聚力。整体控制器对与访问单个目标相关的行为/方法进行分组是强还是弱？

Controller.moveCircleUp() 和 Controller.moveTriangleUp() 会处理访问一个屏幕目标还是两个 ？

在这种情况下，诸如有关整体控制器的广泛问题也适用于整体模型和视图。模型很可能由多个对象组成，用于执行和处理各种事物的数据/状态，因此通常不会对其位置产生混淆。

然而，如果它也是一个整体，那么它必须处理所有屏幕目标的数据/状态。即使在这样的模型中使用多个对象属性和多个方法，这也可能会变得混乱。

可重用性和可维护性

我在这里所写的内容对于代码的可重用性和可维护性来说并不有利。即使您不是 SOLID 专家，也很容易理解为什么单体架构往往会违反单一职责原则。您不应该在同一位置更改圆形的某些内容，同时也对三角形进行更改。

为什么？这样想吧。船翻了之后，你漂浮在海里。这是你和另一名船员。你是否愿意紧密相连，这样如果他失去知觉，他或她也会把你拖倒？不，你会想要独立于船员，这样你就可以自由地自己下沉或游泳。

如果你们在臀部耦合，你们可能会撞到对方的脸，或者犯一些其他错误，而如果每个人都是一个漂浮者，则不会发生这些错误。

换句话说，独立运作并一起工作比齐心协力完成同样的事情要好。这与事情何时进展顺利无关。它是关于什么时候事情出错，或者什么时候独立更可取。例如，当一个人能够抓住直升机上悬挂的绳梯，但另一个人却被鲨鱼啃咬。

您希望能够在不同的屏幕或应用程序中重用应用程序元素。这就是为什么松耦合和强内聚是面向对象编程和一般编程的基础。

（**注意：查看 并不意味着仅 HTML，即使这是最常见的最终结果。其他可能性包括 SVG、XML、Canvas 图形、图像格式...任何适合情况的内容。）

第二个基本问题

2) 屏幕上每个精心设计的可操作对象/元素/目标是否应该有自己的控制器、模型和视图？

用正则表达式来说...

Controller+ (one or more)

Model+      (one or more)

View+       (one or more)

讨论 2

您想在其他页面/屏幕上使用屏幕目标/元素并带来它们的特定行为吗？

在第一个场景中，Controller、Model 和 View 之间存在 1:1:1 关系。它们是整体的。有一个屏幕/网页。在这种设置中，您不能将一个圆放在另一个页面/屏幕上，而不带上三角形的逻辑！

如果目标是使代码在另一个上下文中可重用，那么答案是每个形状都需要一个独立的 MVC 安排。每个目标都有自己的Controller、Model 和View。

实际上，这意味着您指定的每个屏幕元素都知道如何接受事件的输入、处理它并显示输出。不知何故，我们又回到了听起来相当基本的事情上。

---

最后的想法

如果人们接受上述内容为真，那么形状就是活生生的。 :-) 它们独立于上下文。操作它们不应该依赖于首先触发的一些包罗万象的JavaScript、FrontController、事件处理霸主，而只是将工作委托给目标的单个控制器的方法。

PHP MVC

服务器端 PHP 在到达所需的 Controller 子类之前使用 FrontController 方案，因为如果您有一个单点入口在应用程序 (/index.php) 中，您必须将 HTTP 请求 (/contact/send) 转换（路由）到 Controller 的实例，并从该控制器调用所需的方法：ContactController->send()。

性能

这里真正的问题是，在下载所有 JavaScript 并将其加载到用户代理中后，应用程序的性能如何。

回答？你进行的操作越多，你使用的内存就越多。如果每个屏幕元素的 Controller、Model 和 View 至少有三 (3) 个文件，则十个元素可能意味着三十个 (文件下载）至少。

当然，其他配置也是可能的，但这就是某种工具可能会派上用场来连接和缩小所有内容的地方。在 JavaScript 中，我宁愿为每个文件开发一个对象。

我希望这有帮助！