模型-视图-控制器 (MVC)是一种众所周知的架构模式。 这是几乎所有UI和Web框架的事实上的标准。 它既方便又易于使用。 它简单有效。 对于程序程序员来说,这是一个很棒的概念。 如果您的软件是面向对象的,那么您应该像我一样不喜欢MVC。 这就是为什么。
这是MVC架构的外观:
控制器负责处理从Model接收的数据并将其注入到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()
以英里为单位返回速度(以整数表示); FormattedSpeed.speed()
返回"%d mph"
; 最后, PrintedSpeed.to_str()
返回消息的全文。 我们可以称它们为“模型,视图和控制器”,但实际上,它们只是相互装饰的对象。 它仍然是同一实体-速度。 但是通过装饰,它变得更加复杂和智能。
我们不会撕裂速度的概念。 速度就是速度,无论是谁使用它以及在哪里显示它。 它只是从装饰器中获得新的行为。 它会增长,但永远不会崩溃。
总而言之,Controller是MVC三重奏中的一个纯粹的过程组件,它将Model变成了被动数据持有者,而View变成了被动数据渲染者。 控制初探呃 ,保持呃 ,渲染呃 ......难道真的OOP ?
您可能还会发现这些有趣的相关文章: 封装掩盖了裸数据 ; 谁是物体? ; ActiveRecord比ORM更糟 ; 吸气剂/设定者。 邪恶。 期。 ; 责任的垂直与水平分解 ;
您的浏览器禁用了JavaScript,这就是为什么您不能在此帖子下看到评论。