In this interview with Artima, Terence Parr talks about the importance of separating business logic and presentation.

http://www.artima.com/lejava/articles/stringtemplate.html

What do you think about StringTemplate and about Parr's comments on model-view separation?

Another very useful pattern is the Presentation Abstract Controller pattern: http://en.wikipedia.org/wiki/Presentation-abstraction-control

We found that when building UIs, the MVC model worked well for components of the UI but didn't scale well. Instead, the PAC model made things very straightforward and reduced the complexity of managing events.

argh: that should have been presentation abstraction control (its way too early in the morning)

The MV pattern is the most important programming pattern in computer history. It's the only pattern that's essential, i.e. if it's not there, then development and maintenance becomes very difficult and eventually impossible, in the long run.

I agree with Terrence Parr's views on enforcement vs encouragement. I have seen that generally the developers choose the path of least resistance because of fear.

They are afraid whether or not they would be able to finish the work on time. Due to the fear, they hack around until it works, and then move on to the next task. It is very rare to see them refactoring their own code mainly because they are busy with new tasks.

Even when they have the time, they are not going to refactor because of fear again. They do not want to take the risk of breaking things when they refactor.

I have seen discipline among only those developers who are confident of their ability to the finish work on time. But they are generally not the major constituent of a team.

So in the end, we are left with either to enforce good development practices or risk "spaghettisement" of our software.

Same topic, different venue. I wonder whether those who argue for Enforcement when talking about MVC in coding would welcome Enforcement by SQL databases of the Relational Model (as specified by Codd, et al). That is, one would not be allowed to define a schema which was less than X NF (2 < X < 6)??? hhmmm?? Methinks there would be lots of screaming.

One man's bad mixing is another man's *flexibility*.

> One man's bad mixing is another man's *flexibility*.

+1

Cheers,
Carson

> The MV pattern is the most important programming pattern
> in computer history. It's the only pattern that's
> essential, i.e. if it's not there, then development and
> maintenance becomes very difficult and eventually
> impossible, in the long run.

I just can't let that go by. There's nothing "essential" in software development, not even MV. Design decisions have to be made in context.

There are a number of criteria used to decide what level of abstraction is appropriate for a given project. One of them is the probability of change and the difficulty of adjusting to change if it were to come. This has to be weighed against the extra time required to use an abstraction, the increased complexity and reduced performance (not all abstractions suffer from these issues).

I think the term "business logic" derives from a subset of the overall programming domain. Perhaps in a world that consists only of traditional database applications or web applications, the MV rule should be followed blindly, but there's a wider world out there.

"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."
— William Shakespeare

I have to agree with Jeff Ratcliff. MVC design is not something that should always be mandated.

[quote]Who is doing the HTML? Hopefully it is not the coders, because we suck at that. That is not our job. We need a designer to do that.[/quote]

Well I know of applications where there is one person doing both the web design and the coding. Assuming you have a separate person for each of these roles is a flawed assumption in some environments.

> Well I know of applications where there is one person
> doing both the web design and the coding. Assuming you
> have a separate person for each of these roles is a flawed
> assumption in some environments.

You know, only crowds are wise, only teams can solve problems, only designers are creative, only programmers can do math etc.

> [quote]Who is doing the HTML? Hopefully it is not the
> coders, because we suck at that. That is not our job. We
> need a designer to do that.[/quote]
>
> Well I know of applications where there is one person
> doing both the web design and the coding. Assuming you
> have a separate person for each of these roles is a flawed
> assumption in some environments.

There are many more reasons to separate the model (a.k.a business logic/data) from presentation than just team structure. Somewhat to the point, I was just using a web-based application that was developed by a single developer and he had embedded some core logic into the presentation via Javascript. This logic is meant to prevent the user from updating records entered before a certain date. It didn't take me long to look at the source of the pages and figure out how to subvert this logic. If he had kept this logic in the model, it would most likely be impossible to bypass it without access to the host system.

I would argue that team structure is the most unimportant factor in whether to use MVC or not. I am not going to argue that MVC is a must but some form of separation is always a good idea in anything but the most trivial applications.

"I'm a very disciplined programmer, but I am also susceptible to expedience. It is just the way we are. Think about the average programmer. They don't even understand the principle. They are just looking for a way to say what they need to say and they don't think about architecture. So I am trying to actually force good behavior."

the bit about "they don't even understand the principle" rings entirely too true to me these days.

Terence points out some important notions such as logic separation, but I find that he, as well as many people in IT misinterprets the original idea of "MVC" and mistakes it for the "Template" idea, that is another different pattern.

The key point is the meaning of "logic", and the fact that you allways need some logic both in the business layer and in the presentation layer. In fact many MVC evangelists finally use the "Template" pattern claiming to follow MVC pattern, while intermixing business and presentation logic in the Controller.

http://pragmaticj2ee.blogspot.com/2006/03/mvc-is-not-templates.html

Some web frameworks argue that not using MVC is a good idea:

Quote:
"Click is JSP and MVC Free. This is a good thing!

JSP's combined with the miss application of the MVC pattern have been holding back JEE web development for many years. It's a big statement I know, please let me explain.

MVC is a desktop GUI design pattern, which supports a separation of roles in UI design. Model is the data, the View does the rendering and the Control is for modifying the data. Now MVC is a fairly sophisticated UI pattern which solves the problem of multiple views and controls sharing the same data.

For most UI development however MVC is overkill. The control and the view are usually the same thing. For example, a Select box is the view and the control and also holds the model. In Swing fortunately, most of the MVC design is hidden away below the surface. In VB and Delphi there is no MVC at all.

In the early days of JEE web development design patterns were highly converted, and MVC was grabbed and early Servlet/JSP designs were branded as MVC. In their analysis the model was usually a DAO, the view was the JSP and control was a Servlet.

The effect of this was to lock in the design concept where the UI MVC roles were strictly separated. This fits well with the generalized architectural principle separating layers, and with the fact that JSPs are only really suitable for rendering output.

Unfortunately the cost of this strict separation was the encapsulation. Most rich client UI components encapsulate their rendering and control functionality. Click components (Controls) are responsible for both rendering themselves (view) and then understanding what they mean (control).

To see this concept in action take a simple Click page where we have an ActionLink Control. "
(Code example on the original web page)

From
http://click.sourceforge.net/docs/why-click.html