mvc oop_MVC与OOP

mvc oop

模型-视图-控制器 （MVC）是我们都熟知的一种架构模式。 这是几乎所有UI和Web框架的事实上的标准。 它既方便又易于使用。 它简单有效。 对于程序程序员来说，这是一个很棒的概念。 如果您的软件是面向对象的，那么您应该像我一样不喜欢MVC。 这就是为什么。

热点！ （1991）吉姆·亚伯拉罕（Jim Abrahams）

这是MVC架构的外观：

控制器负责处理从模型接收的数据并将其注入到View中，而这正是问题所在。 正如我们之前所同意的那样，数据逃脱了模型并变成“裸露”，这是一个大问题。 OOP就是关于封装-数据隐藏。

MVC体系结构通过暴露数据和隐藏行为来完全相反。 控制器直接处理数据，决定其目的和属性，而本该知道所有有关数据并隐藏数据的对象仍然贫乏 。 这正是任何程序体系结构所基于的原理。 代码由数据负责。 以下面的C ++代码为例：

void print_speed() { // controller
  int s = load_from_engine(); // model
  printf("The speed is %d mph", s); // view
}

函数print_speed()是控制器。 它从模型load_from_engine()获取数据s ，并通过视图printf()渲染。 只有控制器知道数据以英里/小时为单位。 引擎返回没有任何属性的int 。 控制器只是假设数据以英里/小时为单位。 如果我们想在其他地方创建类似的控制器，我们将不得不一次又一次地做出类似的假设。 这就是“裸数据”问题所在，并导致严重的可维护性问题。

这是上述代码（伪C ++）的一种面向对象的替代方法：

printf(
  new PrintedSpeed( // view
    new FormattedSpeed( // controller
      new SpeedFromEngine() // model
    )
  )
);

在这里， SpeedFromEngine.speed()返回以英里为单位的速度SpeedFromEngine.speed()整数）； FormattedSpeed.speed()返回"%d mph" ； 最后， PrintedSpeed.to_str()返回消息的全文。 我们可以称它们为“模型，视图和控制器”，但实际上，它们只是相互装饰的对象。 它仍然是同一实体-速度。 但是通过装饰，它变得更加复杂和智能。

我们不会撕裂速度的概念。 速度就是速度，无论是谁使用它以及在哪里显示它。 它只是从装饰器中获得新的行为。 它会增长，但永远不会崩溃。

总而言之，Controller是MVC三重奏中的一个纯粹的过程组件，它将Model变成了被动数据持有者，而View变成了被动数据渲染者。 控制初探呃 ，保持呃 ，渲染呃 ......难道真的OOP ？

您可能还会发现这些相关的帖子有趣： 封装掩盖了裸数据 ； 谁是物体？ ; ActiveRecord比ORM更糟 ; Getters / Setters。 邪恶。 期。 ; 责任的垂直与水平分解 ；

您的浏览器禁用了JavaScript，这就是为什么您无法在此帖子下看到评论。

翻译自: https://www.javacodegeeks.com/2016/12/mvc-vs-oop.html

mvc oop