Mvc Is Not Object Oriented

In the ObjectWeenie shop I used to work in, ModelViewController was a sacred concept. They would have considered AllenHolub's point of view blasphemy: Model-View-Controller is not Object-Oriented.

See article http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html

The gist of it is that things that should be single objects with information-hiding opaque innards instead become transparent and spread over each of Model, View, and Controller.

Ok, it's interesting, but that's also the typical beginner error of Object design. I agree that this would be ideal to have each object know to do itself everything you want to do with it, print, jumpThroughNetwork, showOnMonitor, and so on. In practice, with object design, you end with objects that have each billion of services and know thousands of layers. That's very tough to manage at any level including for reuse and maintenance purpose. Interaction between those sort of objects would be cool but their internal garbage would be a nightmare. -- BernardDevaux?

So you're saying that you agree with Holub that MVC isn't OO, but that just shows he's an OO newbie, because everyone knows that it would be a nightmare to do an OO version of MVC???

I think that the article seems to complain about naive MVC designs that he's seen "in the trenches." When we talk about MVC, we're talking about turning everything into an event emitter, passing to a stream that aggregates upwards. When the author says that MVC is a poor application design, he is partially correct, because the "Controller" when interpreted as one "object" (which, for the record, he defines by capability) ends up with way (way) too much responsibility, thus breaking whatever tenets of OO you happen to be supporting today.

Big surprise, it's usually bad design. MVC is not especially un-OO in the context it's supposed to be used in. It's called a PatternMisapplication? and it's just bad design decision. You don't blame a pattern for being misused. Perhaps you should rename this page MVCIsAPoorApplicationPattern or something a little less misleading? -- DaveFayram

No, because Holub does make the claim that MVC isn't OO, thus the page name is perfectly on target for his claim, despite the fact that you have a rebuttal. Changing the title would be tantamount to DisagreeingByDeleting. But if you think that there's room for discussion of further issues under that other name, well then, by all means...

It does sound like you have more to say on that topic that would be interesting to hear.

I personally am not ready to take sides on Holub's claim, because although I've been hearing about MVC for years and years and years, every time I think I completely understand the subject, I hear someone claim things about the topic that make me wonder all over again. I'm beginning to think that MVC is like OO itself: many people have many different definitions, including multiple interpretations of what the original MVC was all about.

Earlier today someone said that UI is just a subset of MVC, whereas I would have thought that MVC was a subset of UI, despite the fact that MVC has been applied to non-UI domains, and clearly (?) originally was only about UI...wasn't it?. But what do I know.

I used to know Holub personally, a long time ago, and I thought he was a smart guy who knew lots about lots, but I don't happen to know his OO background in particular, so I can't confirm or deny whether he's an OO newbie.

Well, I won't pretend to understand the implied social implications of renaming this page. :) I read the rest of his paper, and his design seems to make sense from a very limited point of view. However, his solution of instead inverting the relationship and saying to objects, "Instead of me drawing you, you draw yourself on me." isn't really a solution. You still have a dependency. In the case of ATMs (as in the article), ATM hardware is hard to upgrade, so making software that assumes that the requirements may change but the software will not is reasonable. The way MVC works best, in that it gives the most payoff, is when you have a whole lot of good abstractions to build on, then build more.

When a GUI button gets pressed, conceptually what we want is for an event to be emitted. When a model changes, we want an event to be emitted. The controller then serves as a translator to coordinate these events together. These events can contain heavy abstraction, so that when one component changes the events are already prepared to handle it. If you actually make your code actually do that (as opposed to saying methods firing are events like, say, QtDesigner would), then MVC will go a lot further and perform better as an application pattern.

I'm not sure I understand your phrasing when you say "These events can contain heavy abstraction, so that when one component changes the events are already prepared to handle it." Clarify?

Ideally, the events themselves will serve as abstractions. This isn't a cure all, of course. But, it means that you can still have views that consume events, instead of having events that draw themselves into specific types of views. I think a view is far more volatile and subject to change (both during development and deployment) than any other part of the system. Unless, of course, it's not. :)

What I'm describing is basically what the PragmaticProgrammer talks about, so I don't think I'm too far out on a limb here. -- DaveFayram

PragmaticProgrammer talks about MVC?? Or do you mean on a meta level?
- Yes, actually it mentions both the concrete manifestation and the meta-stuff. Starting at Section 29, on page 157, "It's Just a View." -- DaveFayram

Here's another thought: is Holub basically just talking about applying LawOfDemeter to MVC?

I think the way MVC is implemented in J2EE applications using JSP is not very OO. You are placing your data in objects called Beans that represent the View layer and have no logic and are therefore nothing but data structures. All of your logic goes into the part that is usually considered the Model layer, but there is more logic in the Controller layer, so people get confused about what belongs in the controller layer and what belongs in the model. But to me, the idea of separating data from code and putting it into dumb data structures is not very OO. -- WillCardwell

I believe that the above is a simple statement of fact. MVC is a procedural decomposition. The Model contains persistent data access functions. The View contains user interface functions. The Controller is less well defined, except as "glue" between Models and Views.

I don't think that's quite the usual view of MVC, nor does it seem to paraphrase Holub.
- For one possible "usual view" of MVC, please see http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
- Quoting from the above link, "MVC ... organizes an interactive application into three separate modules: one for the application model with its data representation and business logic, the second for views that provide data presentation and user input, and the third for a controller to dispatch requests and control flow." The partitioning is described solely in terms of the functionality of the code decomposition. I would contend that my statement above serves as an adequate paraphrase, but would not object if my original text were replaced with the quoted text. I'll leave it to others to determine which statement brings greater clarity to the discussion.
  - The part that says "the third for a controller to dispatch requests and control flow." is indeed what I would call the "usual view", and does not seem to paraphrase your "less well defined, except as "glue" between Models and Views." - which was the part that concerned me.
- The Holub article does not discuss MVC, per se, it merely asserts that data encapsulation is a primary concern and specifically that getters and setters are a violation of encapsulation. The applicability to MVC occurs because MVC requires data exposure.

A far more interesting topic would be a discussion of cases where MVC would be beneficial and cases where it would not. That, though, would seem to be quite off topic for this page.

I'd like to see such discussion. CostsAndBenefitsOfMvc?

Just because MVC is often implemented in object oriented languages does not make it an object oriented decomposition. The basic terminology describing the components is based on the functionality of the components; this is the definition of procedural software decomposition. Avoid getting caught in the "OO good, procedural bad" mindset. Accept that MVC is procedural and let's try discussing why it may or may not be of value.

Aside from the possibly mythical ObjectWeenie shop at top of page, who said "good/bad" on this page?
- It may be an invalid assumption on my part, but without the good/bad component, I do not see why anyone should take issue with the assertion that MVC is not object oriented. Yes, it is a procedural decomposition, but so what?
You're asserting MVC is procedural...that seems to be an open question on this page, so the point is not to "just accept it", the point is to explain why it is.
- Most of the page seems more targeted to discussing the value of MVC rather than whether it is a procedural or object oriented decomposition. I am merely hoping to separate the discussions so as to do justice to both.
Why it may or may not be of value would be interesting, yes.

one of holub's claims is that multiple views for a model is never done outside of excel. apparently he's never had to render graphs and charts (e.g. work on any kind of financial instrument pricing package and give the end user only one view of the model and watch how many heads roll).

furthermore, data entry/editing is merely a different view than data rendering.

I found holub's article to completely miss the mark of MVC in general... furthermore, I think his concept for the atm model would yield very heavy-weight objects (something I personally dislike).

Now, if he were to say "an object should have one rendering, and that rendering is xml, and a view could render that xml however it darn well pleased" I might amend my thinking. ;)

XML can play a role, but to me it seems a digression.

Holub's completely off the mark. Starting from the false premise that you write a completely new view for every completely new model he arrives at a bogus conclusion. In reality, models are composed and views are composed. The protocol between them also composes in some way. You don't create views that poke around in the innards of models, instead you create factories that build composite models and matching composite views and then seal up the details.

On a more practical note, Holub advocates "direct display", which wires the display logic into every model. MVC allows to provide a new view for an existing model (compare old HTML 2, which could be displayed on a computer, a cell phone, a printer or could be converted to speech), "direct display" destroys that (compare modern HTML "optimized for $BIG_BROWSER", which has to be reinvented as WML to display on cell phones).

This is a benefit of using MVC, in fact it is the whole point of the pattern. But what does this have to do with whether it is object oriented or not?

Mvc is object oriented and Holub is clueless. Don't listen to him.

The point of this page is not to take a "yes/no" poll, the point is to list pro/con arguments. Your arguments are unfortunately inconclusive.

It should be noted that, whether MvcIsNotObjectOriented or not, inherently, it obviously is true that MVC has been done in a non-OO fashion (or in a poor-OO-practices fashion) many times by many projects. That fact (I do think it is a fact) should ideally be addressed in pro/con arguments here: MVC done right is OO/not-OO because...<whatever>, whereas MVC done wrong is not OO because...<whatever2>

MVC might actually be an abstraction of the OO paradigm. The Model is the same as an Objects state. The View is the same as the Objects interface, and the Controller is the same as the Objects implementation. So, in a way, OO and MVC are just presentations of the same idea. Now, if only Java had better meta-information support, building a gui would be as easy as designing an object :-)

I agree that the Model is the object's state (instance variables), but I think the View would actually be its accessor methods, and the Controller would be its mutator methods.

(Moved artical reference to ArgumentsAgainstOop)

See AllocationOfResponsibility.

CategoryNotOo

I agree that getters and setters 'are evil' but I dont agree that the MVC pattern has to use straightforward getters and setters - i.e. things that read the model data and set the model data directly. Houlob says himself that there are situations where you have to ask an object for data - in some form or the other - and thats what the View should be asking of the Model: Not for its internal data, which it isnt interested in, but for a UI-compatible version of that data. That way when you change the internal representation of anything, you arent breakng the View 'getter' because the typethe view is interested in shouldnt change - lets say a String: it doesnt care if thats stored as an int, String, Float or composite in the model itself. Similarly, the controller shouldnt call a setter on the model - it should send it a request that may cause the model to changes an attribute or perform some procedure, according to the models own internal logic.

Houlub has gone one step further, however, and instead of just passing off data to the view in a form that is view compatible, he also gives his 'visual-proxy' the responsibility of drawing that data as well, which is the thing that has people up in arms for all the reasons listed above.

Lastly the multiple view thing where you have a pie chart or a line chart is a bit of a straw man by houlub. That might not be very common, but what is very common is composing screens that use various attribues from many model objects, and I thnk thats another area that people are shooting down the visual proxy idea.

The statement that MVC is not object-oriented stemmed from the lack of such languages as Java or C# when the article was written. Consider the recent work by R. Pawson's group on the 'Naked objects' implementation (both for Java-JVM and for CLR on Windows). Even though some people tend to put 'Naked objects' at the same level as MVC, this is wrong just because the 'Naked objects' is the consistent approach to implemnting the MVC paradigm. Actually, in 'Naked objects' you do not need to implement the View portion of MVC; it is done by the framework for you. The quality of your implementation depends on the level of understanding the problem and the ability to decompose it to the right set of business objects and their interactions. So, I would not state that MVC is not OO by any means even though it has non-object oriented implementations (for languages and environments that existed before OO came to play).

R Pawson adds: FYI In the most recent implementation of Naked Objects for .NET - known as 'Naked Objects MVC' - we've actually made the relationship between the Naked Objects pattern and the MVC pattern both clearer and more explicit. You can write Model objects and get a complete web UI for free without writing any Views or Controllers, just by using the generic, reflective, Views and Controllers. But you can then go on to write bespoke views to customise the presentation and/or bespoke controllers to customise the flow of the application. This gives you the best of both worlds. We cannot prevent people from putting domain logic in their bespoke Views/Controllers (which happens a lot in normal MVC in my experience) but the fact that you don't need to write any Views/Controllers to get going is a good way to encourage developers to put the domain logic where it belongs - encapsulated on the objects. TrygveReenskaug (who was the external examiner for my PhD thesis on Naked Objects) has said that it was the intention (of his group at Parc in the late '70s) to implement something like this, but they never got it done.

"Houlob says himself that there are situations where you have to ask an object for data ... the View should be asking of the Model: Not for its internal data .. but for a UI-compatible version of that data"

- A UI-compatible version of the data is more commonly referred to as a ViewModel?, is it not? So it appears using MVC without a VM is doing it wrong - with no abstraction between the data of the model and the data used by the view, there is a violation of encapsulation and hence not OO.