MVC sucks
It has been my opinion for a while that MVC sucks. It seems to me that it takes away from the OOness of a program. An object should act reflexively -- a piece should move itself, a message should send itself, etc. -- and MVC puts the programmer in this limited mindset of:
Controller -> Model -> View
or
Controller -> View
In this case, the Controller acts on the Model and sometimes the View, and the Model acts on the View. This is subject-oriented programming, not Object-Oriented programming.
Sure, it decouples the controllers, models, and views, but it is often hard to separate the controllers and the views. Furthermore, the controllers and the models often have overlapping responsibilities, which leads to confusion in developing the program.
The Observer-Observable pattern also needs tweaking -- it is not good on its own. If the model sends itself to the view as the single argument in the update method of the Observer's interface, and then the view updates itself according to data in the model (as I have seen done in books), then the view is taking a chunk of the program's logic into its own hands, and the model often ends up with a set&get interface that reveals implementation details. The controller also has a part of the program's logic as well, since it has to update the model upon hearing user events. So what you end up with are sets of controllers, models, and views that divide the program's logic into three parts. Although they decouple the GUI from data, they couple the program's logic into three dependent parts!
The terms Model and Observable give the impression that Models and Observables contain data. They do, of course, but every object does! It's much better to have worker objects that contain 100% of the logic respective to a certain aspect of the program and to pass these worker objects implementations handled as interfaces that allow them to do the work. So in an online service one would have a Message that sends itself and pass it an implementation of an interface that abstracts socket managing. One would also have a User that logs himself on and pass him an interface that abstracts the persistence to the database. One may also have a chess move that asks the Game whether a move is okay and if so moves itself onto the Board that the Game returns.
MVC, however, puts the programmer in a different mindset. It restricts flexibility. Sometimes there are no distinct views and controllers. Oftentimes the logic is coupled with the data. MVC is much more widely-used in web applications than desktop applications. Why is this? It's because web applications are less OO and they are often more focused on event handling and view updating as they often cannot make use of local and remote resources. Separating the UI from worker objects is not the paradigm that I am deriding; it is not only a good idea but it is also an expectation of the programmer. It is MVC, an acronym with three letters -- three parts -- that are often silly to implement. The systematic decomposition of a program into three pre-defined parts and the pre-development assumption that a program will fit this standard are inflexible, restrictive design decisions that not only limit the design of a program but also lead to subject-oriented programming.
Well, back to readingDeath of a Salesman. Did you guys know that the Salesman dies at the end?
[3465 byte] By [
ktm5124a] at [2007-10-2 21:15:12]
I had oatmeal for breakfast.
Owch, I feel invalidated. Is this why you have nearly 30,000 posts?
> Owch, I feel invalidated. Is this why you have nearly> 30,000 posts?Yes. That's all I ever post is reports on my eating, dressing, and elimination. Oh, and family tragedies, like when a moose once bit my sister.
Back to the content of my post (I admit I de-intellectualized this thread as much as jverd)... how applicable, useful, and OO do you think MVC is?
Since I've assumed the role of Official Forum De-intellectualizer today, I'll apply Occam's Lobotomizer and observe that, since MVC has been very widely applied and used for 10 or more years now (because about 10 years ago is when I first heard of it), that it is very applicable and useful. In addition, from the many discussions of it I see here, I would conclude that many people find it to be applicable and useful.
As for it being OO or not, my smartifier is in the shop, so I'm not able to mull over the specifics of your manifesto. I'll just once again take the easy way out and state that it's OO-ness is not all that important. It serves a role. OO is not a panacea for all software problems. As you observed, MVC may be more suitable in some contexts than in others.
So what's the point of your post? Are you just trying to vent your spleen because you don't personally like MVC? The title and some of the content of the intial post would suggest that.
If you want a discussion about MVC, what is your goal? Are you trying to find a replacement? Are you feeling like you must be missing something and looking for feedback on why MVC is so popular? Are you looking for validation, hoping that others will rally around and agree that "MVC sucks"?
> Since I've assumed the role of Official Forum De-intellectualizer today, I'll
> apply Occam's Lobotomizer and observe that, since MVC has been very
> widely applied and used for 10 or more years now (because about 10
> years ago is when I first heard of it), that it is very applicable and useful.
Communism was widely applied and used for more than ten years also.
> As for it being OO or not, my smartifier is in the shop, so I'm not able to mull over the specifics of your manifesto.
Crafty.
> OO is not a panacea for all software problems.
If a program is not going to be OO, should one even consider writing it in Java? Why submit to OO limitations when you are not writing OO code?
>As you observed, MVC may be more suitable in some contexts than in others.
I think MVC is more suitable to other languages.
>So what's the point of your post?
To test my thoughts against professional programmers and see if I am missing anything.
>Are you just trying to vent your spleen because you don't personally like >MVC? The title and some of the content of the intial post would suggest
> that.
I admit I have a slight prejudice against MVC. It was a hindrance and a setback to learning OOP.
> If you want a discussion about MVC, what is your goal?
This post was somewhat whimsical, along with being inspired by the recent thread about MVC in a chess game. Perhaps my answers to your other questions will clarify.
>Are you trying to find a replacement?
The point of my post is not to convince others not to use MVC. It is find out whether I am missing something about MVC.
> Are you feeling like you must be missing something and looking for feedback on why MVC is so popular?
Yes.
>Are you looking for validation, hoping that others will rally around and agree that "MVC sucks"?
I am not looking to rally others around me, but I am looking for validation. In past experience, I have found profane-yet-unoffending titles and strong accusations to be good ways of sparking debate. Once again, this post was somewhat whimsical.
I'm not really interested in getting into a big discussion of architetural philosophy at this point. I will comment on this though:
> > OO is not a panacea for all software problems.
> If a program is not going to be OO, should one even
> consider writing it in Java? Why submit to OO
> limitations when you are not writing OO code?
I don't consider it "submitting to OO limitations." I consider it "taking advnantage of OO features and practices." Java is a general purpose language that is mostly OO in nature but that makes concessions to non-OO programming where its designers felt OO purity for its own sake was counterproductive. You can write very non-OO code in Java (and many do). Maybe you consider that freeing oneself from the shackles of OO tyranny and opression. As for MVC, well, if it's non-OO, then so be it, but I don't see where that bumps heads with Java's OO nature. You can implement a perfectly reasonable MVC in Java.
> I am not looking to rally others around me, but I am
> looking for validation. In past experience, I have
> found profane-yet-unoffending titles and strong
> accusations to be good ways of sparking debate. Once
I disagree. Your subject line and the "here's why it sucks" nature of your post don't invite debate so much as dismissal and derision.
> again, this post was somewhat whimsical.
Well, I've not been able to take this thread very seriously, so it seems you've hit the mark there.
I will also note that I don't agree with the OP's claim that MVC is non-OO. However, since I'm not willing to think about it enough to see if his arguments have merit or to come up with any counterarguments, I'll merely concede that point that it may be un-OO, but, as I mentioned, I don't consider that an automatic negative even if it is the case.
> I disagree. Your subject line and the "here's why it sucks" nature of your post don't invite debate so much as dismissal and derision.
I agree; I should not have done that, especially since I am unsure of myself. Sorry.
Perhaps the reason that I am unsure of myself is because I've always had the impression that the model is supposed to be a "dumb" object that does nothing but store data and inform its views of changes to its data. I now feel that the model is supposed to be a reusable part of the program that handles not only the data but also the logic for a certain aspect. For instance, in a chess game the classes that handle the logic behind the game and the pieces, which depend on the game data, would be the model, correct?
> I agree; I should not have done that, especially
> since I am unsure of myself. Sorry.
>
> Perhaps the reason that I am unsure of myself is
> because I've always had the impression that the model
> is supposed to be a "dumb" object that does nothing
> but store data and inform its views of changes to its
> data.
Maybe you just don't know how to design a model layer properly.
> I now feel that the model is supposed to be a
> reusable part of the program that handles not only
> the data but also the logic for a certain aspect. For
> instance, in a chess game the classes that handle the
> logic behind the game and the pieces, which depend on
> the game data, would be the model, correct?
Yes, correct.
It's Chess Boy. You blew off any advice you got from me in your other thread, so I'll assume that this will be blown off, too. But I'll bite - here's my take on your proposition.
MVC is one of the oldest, most venerable O-O patterns there is. It originated in the Smalltalk community, which is regarded in some circles as the purest of the O-O languages. Maybe you'd like to explain to Kent Beck how little he understands about object orientation.
You can be forgiven - there's nothing wrong with taking a deliberately inflammatory position to elicit a response. But do research this one a bit more carefully. I think MVC is on solid ground here, not you.
%
> > I disagree. Your subject line and the "here's why
> it sucks" nature of your post don't invite debate so
> much as dismissal and derision.
> I agree; I should not have done that, especially
> since I am unsure of myself. Sorry.
No problem. Just making observations.
> Perhaps the reason that I am unsure of myself is
> because I've always had the impression that the model
> is supposed to be a "dumb" object that does nothing
> but store data and inform its views of changes to its
> data.
That was my original impression too. While I'm by no means an MVC expert, my understanding is that the model is not only a data model, but also a business logic model. I believe the model in and of itself can be a large, complex, self-contained OO application or library.
> I now feel that the model is supposed to be a
> reusable part of the program that handles not only
> the data but also the logic for a certain aspect.
That's my take also.
> For
> instance, in a chess game the classes that handle the
> logic behind the game and the pieces, which depend on
> the game data, would be the model, correct?
I would think so, yes. The pieces, their legal moves, the current state of the board, would all be part of the model, to my mind. The view would be the GUI or textual representation of the current state of the board, along with any messages--"Illegal move," "Checkmate," etc.--would be the view, and the controller would be a dispatcher of sorts that sits between the two--taking input from the view and using it to tell the model which move was made (exd5), and reflecting back from the model any new state information (white's e pawn is now on d5, black's d pawn is now gone, black is in check, etc.) to the view.
But then, I could be way off here. Somebody else may come in and correct me.
So, I'm confused now. To your mind, which (pardon the overloaded term) model of MVC is non-OO? The "model is only data" one or the "model is data and business logic" one?
> It's Chess Boy. You blew off any advice you got from> me in your other thread, I don't think this is the OP from the MVC chess thread. I was under the impression he simply read that thread and developed doub^Wquestions.
> It's Chess Boy. You blew off any advice you got from me in your other thread, >so I'll assume that this will be blown off, too. But I'll bite - here's my take on
> your proposition.
I'm not the OP of that thread; I read it and was inspired to make this thread. I'm the one you called "small boy with patterns syndrome" awhile ago =)
> So, I'm confused now. To your mind, which (pardon the overloaded term)
> model of MVC is non-OO? The "model is only data" one or the "model is data > and business logic" one?
The "model is only data" model of MVC is non-OO to my mind. My reasoning is that the model that is only data ends up being a weak object that does too little work. When your model does too little work, your controllers and views must bear the burden, and then you have objects doing too much work and coupling of the GUI and the business logic.
The "model is data and business logic" model of MVC makes sense to me, and now I've come to agree with MVC under that definition. I remember someone saying a while ago that MVC encompasses an entire program. I never understood this until now. Your response about the chess scenario was helpful.
So, despite my derision, I think we've managed to make use of this thread. My gratitude to jverd and duffymo.
Aw man. I was hoping you'd get all snotty so I could insult your parentage, your favorite sports team, and the way your mother dresses you.(shuffles away, hands in pockets, head hung, pouting)
thanks for ruining Death of a Salesman for me, @ssholeyou might have a point about MVC, I don't think many people actually do properly separate the view and controller very often, since the two are usually intertwined in a widget library anyway. but what's your point?
> In this case, the Controller acts on the Model and
> sometimes the View, and the Model acts on the View.
> This is subject-oriented programming, not
> Object-Oriented programming.
MVC is a fairly vague pattern. It's not very specific and has been implemented (and described) in many ways. Also realize that it's different than most patterns because the Model, View and Controllers can be described as patterns in their own right. MVC is often said to not even be a pattern but a strategy. I'll describe how I find it best implemented later in this post.
> Sure, it decouples the controllers, models, and
> views, but it is often hard to separate the
> controllers and the views.
Yes. Often this isn't done. I actually find that there are two classes of controllers: view-controllers and model-controllers which have very different resposiblities.
> Furthermore, the
> controllers and the models often have overlapping
> responsibilities, which leads to confusion in
> developing the program.
There are ways to avoid this but yes, this is a problem.
> The Observer-Observable pattern also needs tweaking
> -- it is not good on its own. If the model sends
> itself to the view as the single argument in the
> update method of the Observer's interface, and then
> the view updates itself according to data in the
> model (as I have seen done in books), then the view
> is taking a chunk of the program's logic into its own
> hands, and the model often ends up with a set&get
> interface that reveals implementation details.
I'll give you a way to avoid this at the end of the post.
> The
> controller also has a part of the program's logic as
> well, since it has to update the model upon hearing
> user events. So what you end up with are sets of
> controllers, models, and views that divide the
> program's logic into three parts. Although they
> decouple the GUI from data, they couple the program's
> logic into three dependent parts!
One thing you might want to think about is that the model is not an Object. It's a layer. Really, all the business (in a general sense) logic should go in the model layer. I think a lot of people get hung up because they think the model is one or more DTOs (a.k.a VOs). Your controller layer should never know anything about the low level Objects like DTOs. You should have a very abstract Model layer API. The controler is there to link up the model to the View. The reason to keep it separate is so you can link different views to the model and different models to the view. In practice the latter is less common because the View has to be very abstract so the controller is lumped in with the view. There is another problem people tend to have in that a lot of stuff that has nothing to do with the model is put in the controller layer. This is the view-controller that I mention above. Linking view events back to the view (or other views) is really very different than linking them to the model so I prefer to keep that in the view layer (though you can keep the logic in separate classes or even a sub-layer, if you want to get really crazy.)
> MVC, however, puts the programmer in a different
> mindset. It restricts flexibility. Sometimes there
> are no distinct views and controllers. Oftentimes the
> logic is coupled with the data.
I'm not going to say that doesn't happen but it's absolutely a violation of MVC principles.
-
OK, after struggling with this a good bit as you seem to be, I've found that a good way to build the Model layer is to use the Builder pattern (GoF). In this way, the model says to the view, 'build me' and hands it the data it needs to render the model. It takes a little while to rearrange a program to do this but once you do, a lot of the problems you mention disappear (a few new ones do appear: nothing insurmountable.) The real value is that it is highly decoupled. For example, I cobbled together a flat file parser from some old code and built a Bulder layer. Once that initial work was done, I was able to hammer out new views in hours. In a few days I have a text view, an updateable SWT view, a Swing view, and I actually implemeted the code to write out modifed files as a view. None of these new views required changes to the model. I even implemented the Swing view months later with ease. I just had to implement the builder API and I was done.
I actually do very little GUI work in my currrent role and the MVC pattern is applicable to sockets, document rendering (e.g. XML) and any other type of representation you can imagine. Using the Builder pattern makes the promise of MVC become reality.
> For example, I cobbled together a flat
> file parser from some old code and built a Bulder
> layer. Once that initial work was done, I was able
> to hammer out new views in hours. In a few days I
> have a text view, an updateable SWT view, a Swing
> view, and I actually implemeted the code to write out
> modifed files as a view. None of these new views
> required changes to the model. I even implemented
> the Swing view months later with ease. I just had to
> implement the builder API and I was done.
Interesting. I would like to make sure that I understand the last part of your post correctly. So let's say the flat file that you are parsing consists of a database of birds from an aviary (I have birds and love them). The parser figures out the structure and ascertains the names, genders, and ages of all of the birds in the database. It then hands this information to the view, perhaps as a bunch of arrays, and the views use this data with a Builder to build a JOptionPane window. This way the logic in rendering the model is isolated to a Builder rather than scattered among views. Is this scenario correct?
> Interesting. I would like to make sure that I
> understand the last part of your post correctly. So
> let's say the flat file that you are parsing consists
> of a database of birds from an aviary (I have birds
> and love them). The parser figures out the structure
> and ascertains the names, genders, and ages of all of
> the birds in the database. It then hands this
> information to the view, perhaps as a bunch of
> arrays,
A more object-oriented approach would have a Bird class, with name, gender and age attributes. There's be a BirdDAO interface for the persistence layer. There's be a BirdService interface that would take client requests for CRUD operations on Birds. There would be BirdController that would stand between the UI and the service layer to field client requests. It would shield the service layer from the view and visa versa. It would package up the response from the service layer and give it to the view to display. The controller would know about the view and service layers, but neither would know about each other.
That's the way I think about MVC.
%
> Interesting. I would like to make sure that I
> understand the last part of your post correctly. So
> let's say the flat file that you are parsing consists
> of a database of birds from an aviary (I have birds
> and love them). The parser figures out the structure
> and ascertains the names, genders, and ages of all of
> the birds in the database. It then hands this
> information to the view, perhaps as a bunch of
> arrays, and the views use this data with a Builder to
> build a JOptionPane window. This way the logic in
> rendering the model is isolated to a Builder rather
> than scattered among views. Is this scenario correct?
What you would do is create an aviary builder interface that would have methods like addBird(Species s, Gender g) etc. Then your controller takes a model and calls the appropriate methods on the builder interface as it iterates (or walks) the model. Then each view you wish to create implements the addBird() method as appropriate.
If you don't have the GoF book, you should consider buying it. You can also find a good bit of info on the Builder pattern via Google.
Ah, so the view is the buider, and the model or controller helps builds the view by providing the data that the view will need to build itself (render the model). I thought that the view delegated that responsibility to something else -- a helper object separating the view from the building logic. This seems like unnecessary and perhaps detrimental abstraction, though.
> I'm not the OP of that thread (...) I'm the one you called> "small boy with patterns syndrome" awhile ago =)That leaves us with 2743 possibilities for your idendity :o)
> Ah, so the view is the buider, and the model
> or controller helps builds the view by providing the
> data that the view will need to build itself (render
> the model). I thought that the view delegated that
> responsibility to something else -- a helper object
> separating the view from the building logic. This
> seems like unnecessary and perhaps detrimental
> abstraction, though.
Why would the view delegate it's primary responsibility (rendering the data) to another class?
> That leaves us with 2743 possibilities for your
> idendity :o)
I'm wearing a blue shirt. It has black letters on it.
> Why would the view delegate it's primary responsibility (rendering the data) to another class?
Good point.
Thanks for all the MVC advice. I've learned a lot from this thread.
