题 模型 - 视图 - 控制器是否面向对象设计不佳? [关闭]


OOD(面向对象设计)和MVC(模型 - 视图 - 控制器)架构已成为现代软件设计的主要内容。然而,我最近有一个关于MVC架构如何利用的有趣讨论(甚至可能 违反)OOD原则。这种可能性实际上相当有趣,因为OOD和MVC都旨在实现许多相同的目标:关注点分离和软件可重用性。但我提出的问题是: 这两种设计策略是否与彼此直接冲突?  正如我在实践中使用过的那样,我开始思考:很可能是的。

我这样说是因为:在模型,视图和控制器之间实施严格的分离通常会导致模型实现为哑的架构 集装箱 只能通过外部控制器操纵。我认为这直接冲突了面向对象设计的主要原则之一:对象包含执行必要操作的操作,并在必要时封装它们。例如,在一个纯粹的面向对象架构中的一个假设 File class将包含诸如的方法 open() 和 save()。 MVC建议我们有两个班级 File 和 FileManager (这样后者包含了 open() 和 save() 方法)。对我来说:MVC设计相当混乱。如果需要创建一个更专业的类型 File (比如说处理通过网络传输的文件 open() 要么 save()),一个只需要分类 File 有一个叫做的课(让我们说): StreamedFile。使用MVC,您必须创建另一个管理器类或使原始管理器类的设计复杂化。

由此, 因此,在一个更复杂的系统中,MVC可能会对关注点分离和代码重用性产生灾难性影响。或不?也许MVC模式可以在不破坏OOD原则的情况下实现?或MVC本质上是一种有缺陷的方法,难以实现松散耦合组件的软件系统? 


16
2018-04-25 20:23


起源


有关: softwareengineering.stackexchange.com/questions/168316/... - AlikElzin-kilaka


答案:


相反,健康的MVC使用应该鼓励 枯瘦 控制器和 脂肪 模型,以便模型(对象)是动作发生的地方(它本身鼓励封装和其他良好的OOP原则),控制器只是指向对象的正确方向的某些请求。


14
2018-04-25 20:32



并且OOD不鼓励瘦弱和肥胖的课程。它鼓励在其头等公民(物品)之间分配重量(和食物)。 - AbiusX


MVC中没有任何内容可以说明 Model 应该是愚蠢的(贫血模型)。我认为拥有富人是完全合适的 Model 课程,消除了“经理人”的需要。

话虽如此,它是目前流行的做法 ViewModels用于将数据传递给 ViewViewModel 基本上是你的投影 Model 专门针对特定的 View。它可以被视为 Model 从 View的观点,富人的门面 Model;所以当然还有更多的东西 Model 而不仅仅是 ViewModel


5
2018-04-25 21:12





我不会把MVC称为与OOD同样痛苦的架构。 MVC只是一种可以应用于某些设计的OOD模式。因此它很简单,不会与OOD竞争,它只是构建好或坏OOD设计的工具之一。就像锤子不能与良好的木工艺竞争一样,锤子就像MVC一样,只是工匠工具箱中的工具。

它既不是促进不良设计的模式。因为良好的OOD设计可以很好地分离关注点,所以MVC模式可以通过将表示关注点(视图)与应用程序逻辑(控制器)和更基本的域逻辑(模型)分开来为您提供。因此,它是一种经常应用于用户界面的良好OO模式。但是在制作好的OOD时还可以考虑其他竞争模式。


1
2018-04-25 21:11





我们有两种形式的MVC,Pull MVC和Push MVC(又名基于组件的MVC和Legacy MVC)。

推动MVC专注于概念的分离,每个模型 - 视图 - 控制器集处理应用程序的某些方面,并且可以由一些单独的人员设计和开发。当系统快速开发时,它运行良好,并且添加功能也很容易。大型系统中的代码重用变得非常糟糕。基本上只有模型被重复使用。

Pull MVC,通过使用小部件(视图组件)专注于代码重用,以便许多视图共享相同的代码并仅自定义其小部件。对于控制器,通用控制器实践被抽象和执行。

这是根据软件的性质和速度混合Pull和Push MVC的问题。


1
2018-03-16 11:52



很有意思。就我个人而言,我是否会将两种形式的MVC描述为“推”或“拉”,因为你所做的命运更多的是关于视图/模型边界的代码可重用性分布,而不是关于哪一方面应用程序可以更好地控制执行流程。另一方面:这种实施模型的现象,仔细关注OOD,同时快速拍打视图已经是常见的做法。随着大量应用程序智能向客户端移动,我看到你所谓的“拉动MVC”获得动力。 - Ryan Delucchi
我相信控制器应该是路由器。路由器关键字用于javascript mvc框架,甚至java spring控制器应该是路由器和数据绑定器。但在传统的MVC风格中,集中模型,集中式控制器和集中式视图在思考和编码过程中难以查找,并且在切换环境中浪费时间。我相信MVC的时间已经结束,基于组件/小部件的框架更受欢迎。 - samarjit samanta