MVC 设计模式中的控制器

Controller in MVC design pattern

我想问一下,在 MVC 中,为什么我们需要 controller.why 我们不直接连接模型,如果我们没有控制器,view.what 会是问题吗?

关注点分离,它使程序更易于维护,并允许我们向系统的不同部分添加更多功能而不会破坏其他部分,因为它们彼此独立... https://en.wikipedia.org/wiki/Separation_of_concerns

因此,如果您的域的代码和它应该如何提供给视图的逻辑以及处理屏幕上数据显示的代码都在一个地方,那么它就很难您可以更改部分域代码,而不必更改将其移动到视图的部分逻辑以及随后呈现它的代码。使用控制器,我们可以将逻辑移动到另一个 class 并使其成为独立于视图,所以当我们修复或修改我们的应用程序时,我们只需要关注 MVC 模型的一部分...

MVC 是一种软件架构设计模式,通过划分代码,它使代码更具可读性、可维护性和可移植性。

如果你去掉控制器会有很多缺点。包括但不限于:

您的代码结构不会像在 MVC 中那样清晰。因此,模型中将存在更多代码。它更难阅读和维护。

代码将失去部分可移植性,例如您的模型(数据库、文件、数据...)还需要包含视图函数、调用和委托。因此,如果您想将同一个模型与不同的 UI 框架一起使用,您将需要重写或编辑它。就像将应用程序从 Mac OS X 移植到 iOS.

...

控制器像胶水一样工作,它将模型和视图绑定在一起。

分离表示模式背后的主要 'drivers' 之一是可测试性。控制器允许测试表示逻辑。

控制器是您连接 'model' 和 'view' 的地方。有两个不同的领域,两种不同的语言;视图使用 "string language",应用程序使用另一种语言(比如 Java 语言)。

至少需要那些;

  • 正在转换视图参数;它们由用户作为字符串输入到语言对象,例如数字、日期等...
  • 正在验证视图参数;它们来自用户,可能格式不正确甚至是恶意的。
  • 创建模型对象,(或直接访问数据库)。
  • 错误报告,如果出现问题。
  • 正在更新视图以表示模型的新状态。

可以 hide/automate 控制器工作的某些部分;声明式验证、根据请求自动创建模型对象、将模型对象绑定到视图层(例如 JavaBeans)。

但这不是控制器的替代品;
Controller 不是我们写的代码,它是 "logical place" 一些职责被放入的。即使它不可见,但对于以前用 MVC 思考的人来说,它仍然存在。