模型 - 视图 - 控制器是否面向对象设计不佳？

Question

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

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

由此,可以得出在一个更复杂的系统MVC可能对关注和代码的可重用性分离都带来灾难性的后果.或不？也许MVC模式可以在不破坏OOD原则的情况下实现？或者,MVC本质上是一种有缺陷的方法,难以实现松散耦合组件的软件系统？

Answer 1

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

Answer 2

MVC中没有任何东西说这Model应该是愚蠢的(贫血模型).我认为拥有丰富的Model课程是完全合适的,这可以消除"经理人"的需要.

话虽如此,目前流行的做法是使用ViewModels将数据传递给View.ViewModel基本上是您Model专门针对特定情况量身定制的投影View.它可以被看作是Model从View的角度来看,丰富的立面Model; 所以当然还有更多Model不仅仅是ViewModel.