Is Model-View-Controller Poor Object-Oriented Design? [closed]

Question

Both OOD (Object-Oriented-Design) and MVC (Model-View-Controller) architectures have become staples of modern software design. Yet, I have recently had an interesting discussion regarding how MVC architectures utilize (and possilby even violate) OOD principles. This possibility is actually rather intriguing since both OOD and MVC are intended to achieve many of the same goals: separation-of-concerns and software re-usability. But the question I pose: Are these two design strategies in direct conflict with each-other? As I have used both, in practice, I am beginning to think: quite possibly yes.

I say so because: Enforcing a strict separate between models, views and controllers often results in architectures where models are implemented as dumb containers that can only be manipulated via external controllers. I argue this directly conflicts one of the chief principles of object-oriented design: where objects contain operations that perform necessary operations and encapsulate them as necessary. For example, in a pure Object-Oriented architecture a hypothetical File class would contain methods such as open() and save(). MVC suggests that we have two classes File and FileManager (such that the later contains the open() and save() methods). To me: the MVC design is rather messy. If ones needs to create a more specialized type of File (say for handling Files that stream across a network on open() or save()), one only needs to sub-class File with a class called (let's say): StreamedFile. With MVC, you'd have to either create another manager class or complicate the design of the original manager class.

From this, it follows that in a more complex system MVC could have disastrous effects on both separation of concerns and code re-usability. Or Not? Perhaps MVC patterns could be implemented without breaking OOD principles? Or Is MVC an inherently flawed approach that makes it difficult to implement software systems with loosely coupled components?

Answer 1

On the contrary, healthy MVC use should encourage skinny controllers and fat models, so that the models (the objects) is where the action happens (which itself encourages encapsulation and other good OOP principles), and the controllers are merely there to point certain requests in the right direction to the objects.

Answer 2

Nothing in MVC says that Model should be stupid (anemic model). I think it is completely appropriate to have rich Model classes, which eliminate the need of 'managers'.

That being said, it is currently popular practice to use ViewModels for passing data to a View. ViewModel is basically a projection of your Model tailored specifically for a particular View. It can be regarded as Model from View's perspective, a facade for a rich Model; so of course there is much more to a Model than just ViewModel.