Some people firmly believe in "Separation of logic and view", aka, "separation of model and view", aka several other things.

Here are some pros/cons, that may point to the idea that ModelViewController is YouArentGonnaNeedIt.

''YAGNI is a noun now?''

Requiring "business objects to know nothing about serialization":
	* Pro: '''Deduplication''' -- If objects themselves had methods to write themselves to the DB, it would be tempting to just slap in some SQL/JDBC code to do it. Since we're required to put this elsewhere, we've made sure to deduplicate that. 
	* Con: '''Slowing us down''' -- We'd be going much faster if we just did adhoc SQL -- it took a week to make a generic object-serializer (we were converting from file-based persistence), and we still don't have something that's generally useful. ''Did you really need to build a '''generic object serializer'''?''
	* Con: '''Duplication''' -- Now, for every "business object", there is a parallel hierarchy that does nothing but describe the business objects, and talk to the persistence layer.
	* Pro: '''Separation of concerns''' -- While each business object has some other object that knows how to persist it, there is a clean '''separation of concerns''', and each abstraction/business object deals with domain related details.

''Since in SmalltalkLanguage we can ExtendClass in a different package, you don't need a ParallelClassHierarchies. You put all the model methods in the model package (along with their classes) and, if required, put a view method in the view package. I've refactored quite a few ParallelClassHierarchies like this, and reduced the number of classes by 50% in some instances. On a separate note, the Smalltalk community has thrown up some alternatives to MVC. You should check out Morphic where the GUI acts directly on the model. -- DanielPoon''

Requiring that all HTML goes in one place (i.e., JSP, other templates), and logic goes in this other place.
	* Pro: '''Giving us a place to put volatile-yet-simple HTML''' -- If programmers had to write tests for all HTML generation, there would be a number of tests that don't provide any benefit.
	* Con: '''Less test coverage''' -- Inevitably, you end up with some amount of logic in the "view". This logic is only tested by end-to-end tests, if you have them. It's much easier to put this logic in a UnitTest''''''able place.
	* Con: '''HTML-generating Duplication''' -- Rather than spotting view-to-view duplication, and writing simple, beneficial abstractions (such as a table-printer), we just copy and paste and change.
	* Con: '''Object structure Duplication''' -- Right now order.getTotal() returns a float. If you changed it to return a "Money" object, then you'd have to change multiple, distant locations. GroupSimilarDecisions. ''Question is -- whats your answer to this?''

...anyone else have any more to add? So far, I can't help but think that this is yet another pair of InvisibleHandcuffs that programmers allow themselves to wear.

''There's something about MVC especially as it is implemented in (a lot of) EJB and JSP applications that smacks of a regression. We separate the methods and the data that they operate on in order to gain "flexibility". We pay to maintain that flexibility even when we don't need it. Has anybody tried building a system with "whole" objects (ones that know how to save themselves to the database) in a system backed by a relational database? I would like to hear how many people have needed to change the entire back-end of their system (we moved from SQL Server to Oracle) and how much their separation of everything helped or hindered them. How many people have changed the entire front-end of their application (I'm not talking about stylesheets here)? Could these changes have simply been refactorings or was the flexibility to perform them needed up front?''

I've never had to do anything as heavy duty as change a DB engine midstream. But the current project I'm working on (RubyLanguage ecommerce site, about 15KLOC) has a pretty good object-relational bridge going on, and it's made writing UnitTest''''''s a million times easier. My tests don't touch the database -- I just mock out the DB wrapper (called the "O''''''bjectStore" in my app) and stuff it full of mock domain objects. Works like a charm.

One thing to note is that the cost of such a thing differs depending on certain choices such as language, development tools, etc. The reflection in RubyLanguage is maybe 100 times more elegant than the reflection in JavaLanguage, and my object-relational separation uses a ton of reflection. I implemented a similar thing in JavaLanguage, on a different project, and it took a lot more work. With that language it's easier to imagine people asking "Why are we going through all this trouble?" -- francis
----

Pro: '''Giving us a place to put volatile-yet-simple HTML''' -- If programmers had to write tests for all HTML generation, there would be a number of tests that don't provide any benefit.

''Why would you '''not''' write tests for the HTML generated by your application? I mean, I know most people don't, but what benefit is it that those tests would not provide?''

Tests that do nothing but restate what the code says probably don't have much value. For example:

Code:
 String title() {
  return "<h1>" + title + "</h1>";
 }
Test:
 void testTitle() {
  assertEquals("<h1>foo</h1>", o.title());
 }
If you change it from <h1> to <h2>, you just update the tests.

The important thing here to remember is that tests are redundancy. Now, RedundancyIsInertia, and we normally want a little redundancy to keep us from accidentally shedding good features. However, this is probably just the burdensome kind of inertia.

''Good page. I've been wondering about this question as well. -- JimLittle''

More Generally: FalseDistinctionInCodeBetweenBusinessAndTechnical
----

OK, I'll bite. Assume that in the above "testTitle" is not present, and browsing through the code I'm struck with the fine idea of refactoring title() to:

 String title() {
  return title;
 }
Should I expect someone to complain, or ?..

Now, the original title() has duplication. It might be refactored to

 String title() {
  String tag = "h1";
  return "<"+tag+">" + title + "</"+tag+">";
 }

or even (express all distinct ideas)

 String title() {
  return tag("h1",title);
 }

 String tag(String tag, String content) {
  return "<"+tag+">" + content + "</"+tag+">";
 }
Now all of a sudden it seems that a test for tag() might indeed have some value. We wouldn't want that slash in the closing tag to go missing or be misplaced.

So what do you think is happening here?
----

See Also: YagniAndDatabases