Under MVC, business rules belong in the __________


#1

Railsters:

I heard a rumor that the incorrect answer, “Controller”, was in
circulation out
there.

The C should be as thin as possible, like a telephone patch-board. The
View
should be thick, but only with Viewey things.

The Model should be as fat as possible. Anything a user can do to the
biz rules,
thru the View, unit test can do to the Model directly.

So the question is: Where did this disinformation come from? Do any
websites (or

cough< books) out there actually say the biz rules belong in the
controller?


Phlip


#2

Phlip wrote:

Railsters:

I heard a rumor that the incorrect answer, “Controller”, was in
circulation out
there.

Where did you hear this rumor? At least within the Rails circles I’m
aware of thin controllers and fat models are the mantra.

The C should be as thin as possible, like a telephone patch-board. The
View
should be thick, but only with Viewey things.

The Model should be as fat as possible. Anything a user can do to the
biz rules,
thru the View, unit test can do to the Model directly.

In the context of Rails’ MVC this is what’s generally promoted. However,
Rails is not the only application of MVC out there and it certainly
wasn’t invented along with Rails.

For example: I also work with the Mac OS X Cocoa framework, which is
also very much MVC based. However, it’s very common to have fat
controllers. This is not a problem, and is highly promoted. The reason
for this is that controllers in Cocoa serve a somewhat different role in
the design of Cocoa based desktop applications. They are often used as
delegates for windows, views, persistency related objects, etc. They are
often used for handing notifications that are broadcast between objects,
and there are many other uses for them. There’s nothing wrong with this
and it doesn’t “break” MVC or anything else. It’s just a different
approach that makes sense in it’s own right.

So the question is: Where did this disinformation come from? Do any
websites (or

cough< books) out there actually say the biz rules belong in the
controller?

I can’t answer that, because I’ve not heard these rumors you speak of.


#3

On Wed, May 27, 2009 at 10:34 AM, Robert W.
removed_email_address@domain.invalid wrote:

Phlip wrote:

Railsters:

I heard a rumor that the incorrect answer, “Controller”, was in
circulation out
there.

Where did you hear this rumor? At least within the Rails circles I’m
aware of thin controllers and fat models are the mantra.

Thin controllers.
Fat models
Dumb views

Although as I type this maybe Thick as a synonym for Dumb might be a
better fit with the other two.

And to drive the point home:
http://www.railsenvy.com/2008/6/3/mvc-videos

Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale


#4

On Thu, May 28, 2009 at 10:17 AM, Jeff S. removed_email_address@domain.invalid
wrote:

logic.
Well that’s not the original intention of Trygve Reenskaug when he
conceived of MVC:

http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

Trygve’s original goal was separating UI logic from domain logic (what
we commonly cause Business logic). The Model holds the domain
information and methods for processing it.

The View is concerned only with presenting the view to the user, a
model might have multiple views presenting different subsets and/or
projections of the model.

The Controller deals with communicating with the user, it processes
user input, and decides which views should be rendered and where.

So the Rails notion of MVC seems very similar to this 1979 version.
Controllers process user input and decide which view to render, Views
do the rendering, and Models do the heavy application lifting.

Subsequent variations of MVC, particularly those which piled
application logic into the controller are perversions of the original
idea.

Note also that Reenskaug talks about Editors which are objects which
are associated with a view and are temporarily interposed between a
controller and a view. I think if you squint just a little bit you
can see the seeds of what Rails developers now refer to as a
Presenter.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale


#5

Rick DeNatale wrote:

Well that’s not the original intention of Trygve Reenskaug when he
conceived of MVC:

http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

Thanks, I’ll read that as soon as I have a chance.

Trygve’s original goal was separating UI logic from domain logic (what
we commonly cause Business logic). The Model holds the domain
information and methods for processing it.

The View is concerned only with presenting the view to the user, a
model might have multiple views presenting different subsets and/or
projections of the model.

The Controller deals with communicating with the user, it processes
user input, and decides which views should be rendered and where.

That’s different from any form of MVC I’ve ever heard of, including
Rails. Ordinarily, the views define the UI, and the Controller exists
strictly behind the scenes, as implementation details.

So the Rails notion of MVC seems very similar to this 1979 version.
Controllers process user input and decide which view to render, Views
do the rendering, and Models do the heavy application lifting.

That’s not how Rails works. You’re mostly right about the Models, but
the controllers are, as Phlip suggested, just “patch boards,” not for
user input. Sometimes a savvy user can send HTTP requests to a Rails
application without going through any view, but that’s not the intent.

One piece of “heavy lifting” still done by the controllers is access
control; Models know how to answer questions, and don’t intrinsically
care who’s asking. It’s up to the Controllers to determine who gets to
see what.

Subsequent variations of MVC, particularly those which piled
application logic into the controller are perversions of the original
idea.

“Perversions.” You know, there are ways of making a point that don’t
involve blanket insults of everyone who disagrees with you.

Note also that Reenskaug talks about Editors which are objects which
are associated with a view and are temporarily interposed between a
controller and a view. I think if you squint just a little bit you
can see the seeds of what Rails developers now refer to as a
Presenter.

I’ll have to look up Presenter.


#6

I didn’t read it as an insult…according to the dictionary:

'perversions: a perverted form of something'
'perverted: turned from what is right; misguided; distorted.'

Then every MVC implementation that differs from the original is indeed
‘distorted’ and therefore ‘perverted’

Do we really need to try and interpret everything as flamebait?


#7

Phlip wrote:

Railsters:

I heard a rumor that the incorrect answer, “Controller”, was in circulation out
there.

That’s how I was taught MVC, long before I’d heard of Ruby: Models do
some basic checking, but business logic belongs in the controller. That
was the point of the controller; it gave a central place to put business
logic.

The C should be as thin as possible, like a telephone patch-board. The View
should be thick, but only with Viewey things.

That’s the Rails take. Rails munges terminology a little. Rails models
do a lot of what used to be done by controllers. I’m not saying it’s a
bad thing, but MVC far predates Ruby, and supposed “best practices”
change over time.

The Model should be as fat as possible. Anything a user can do to the biz rules,
thru the View, unit test can do to the Model directly.

That’s not necessarily true.

So the question is: Where did this disinformation come from? Do any websites (or

cough< books) out there actually say the biz rules belong in the controller?

I first used MVC with MFC, about 10+ years ago, and in Java shortly
thereafter. Fat controllers may have been advocated by MS back then.


#8

Brian wrote:

I’m new to both rails and MVC, so please correct me if I
misunderstand. But it seems that controllers DO handle user input for
the typical web application. A view helps a user format that input,
but it can’t receive anything. In fact, I could just send an http
request to a rails application before ever interacting with UI. The
controller is what processes this request, consulting models if
necessary. The view isn’t involved until the application tries to
send information back to me.

You could, but you ordinarily don’t. A user typically deals with a web
page, entering information in (e.g.) a styled form. The controller only
deals with “input” in the sense of HTTP requests, and it doesn’t know
whether they come directly from some hacker, or from an XMLHttpRequest
object in some Ajax application. In such a case, btw, the Controller
sends back XML directly, without going through the view; so, if we’re
going to take the stance that Controllers deal with input directly, then
we also have to see them as providing output directly. It makes more
sense, IMO, to see the View as defining the UI, and the Controller as an
implementation detail.


#9

p_W wrote:

I didn’t read it as an insult…according to the dictionary:

'perversions: a perverted form of something'
'perverted: turned from what is right; misguided; distorted.'

Then every MVC implementation that differs from the original is indeed
‘distorted’ and therefore ‘perverted’

“Perversion” is an extremely derogatory term. That connotation may not
be expressed by your dictionary, but I assure you, “perverse” is a very
nasty way of referring to something, and implies strong disapproval.
The most common use of the word is probably in relation to sex crimes.
It’s just not a nice thing to say. That doesn’t mean Ron hasn’t got the
right to say it, especially if it accurately expresses his opinion;
however, it’s not something that ordinarily comes up in civil discourse.

Do we really need to try and interpret everything as flamebait?

Do we really need to turn every intellectual debate into a struggle for
personal superiority? It’s silly. If I told my coworkers their
opinions were “perverse,” I wouldn’t have coworkers anymore.


#10

On May 28, 11:29 am, Jeff S. removed_email_address@domain.invalid wrote:

That’s not how Rails works. You’re mostly right about the Models, but
the controllers are, as Phlip suggested, just “patch boards,” not for
user input. Sometimes a savvy user can send HTTP requests to a Rails
application without going through any view, but that’s not the intent.

I’m new to both rails and MVC, so please correct me if I
misunderstand. But it seems that controllers DO handle user input for
the typical web application. A view helps a user format that input,
but it can’t receive anything. In fact, I could just send an http
request to a rails application before ever interacting with UI. The
controller is what processes this request, consulting models if
necessary. The view isn’t involved until the application tries to
send information back to me.


#11

On Thursday 28 May 2009, Jeff S. wrote:

Phlip wrote:

Railsters:

I heard a rumor that the incorrect answer, “Controller”, was in
circulation out there.

That’s how I was taught MVC, long before I’d heard of Ruby: Models
do some basic checking, but business logic belongs in the controller.
That was the point of the controller; it gave a central place to put
business logic.

That sounds more like Jacobson’s Entity-Boundary-Control. Is there a
chance you’re thinking of that?

Michael


Michael S.
mailto:removed_email_address@domain.invalid
http://www.schuerig.de/michael/


#12

On Thu, May 28, 2009 at 2:57 PM, Jeff S. removed_email_address@domain.invalid
wrote:

“Perversion” is an extremely derogatory term. That connotation may not
be expressed by your dictionary, but I assure you, “perverse” is a very
nasty way of referring to something, and implies strong disapproval.

I’d suggest it’s a serious mistake to assume your odd point of view –
which doesn’t match up with either the m-w.com dictionary, or my own
experience – is shared by the majority.

Your assurances notwithstanding :slight_smile:


Hassan S. ------------------------ removed_email_address@domain.invalid


#13

Michael S. wrote:

That sounds more like Jacobson’s Entity-Boundary-Control. Is there a
chance you’re thinking of that?

No, what I’m describing was a dominant view of MVC in the late 90’s. Of
course, that doesn’t make it right, and maybe it should have been called
Entity-Boundary-Control. Thanks for giving me something to Google.


#14

On Thu, May 28, 2009 at 11:29 AM, Jeff S. removed_email_address@domain.invalid
wrote:

Rick DeNatale wrote:

That’s different from any form of MVC I’ve ever heard of, including
Rails. Ordinarily, the views define the UI, and the Controller exists
strictly behind the scenes, as implementation details.

By UI I mean both output and input. And the Controller and View are
both involved.

So the Rails notion of MVC seems very similar to this 1979 version.
Controllers process user input and decide which view to render, Views
do the rendering, and Models do the heavy application lifting.

That’s not how Rails works. You’re mostly right about the Models, but
the controllers are, as Phlip suggested, just “patch boards,” not for
user input. Sometimes a savvy user can send HTTP requests to a Rails
application without going through any view, but that’s not the intent.

No, I really understand how Rails, HTTP browsers work, and I maintain
that controllers handle input and decide how to change what the user
sees in response. This is partially in response to a later response
you made to Brian.

if we step back and see how the user interacts with a web application
through a browser, the first step is to make the initial request by
getting the browser to send an http request to the app. This happens
when he does something like typing a url into the address bar, or
following a link.

The http request, typically a get here is the input I’m talking about.
That input in the form of a request is routed to a controller, which
typically interacts with one or more models, then renders something.
That something is typically an html page from a rendered view, but
could also be json, javascript, or a partial dom replacement for an
ajax call, often view are involved in the rendering of this response.

The only thing that views have to do with input is to provide
affordances by which the user may cause additional input requests to
happen, whether they be links, buttons which generate ajax requests,
etc. but the input is processed by the controller in the web
application.

One piece of “heavy lifting” still done by the controllers is access
control; Models know how to answer questions, and don’t intrinsically
care who’s asking. It’s up to the Controllers to determine who gets to
see what.

Only in the simplest of access control. Usually there’s model
involvement here as well, although it’s often not obvious because the
controller interaction with the security model objects is done in
before filters.

Subsequent variations of MVC, particularly those which piled
application logic into the controller are perversions of the original
idea.

“Perversions.” You know, there are ways of making a point that don’t
involve blanket insults of everyone who disagrees with you.

As others have pointed out, you are over reacting to the word. The
intention here was in the same sense as “a perversion of justice”. No
insult was intended.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale


#15

Subsequent variations of MVC, particularly those which piled
application logic into the controller are perversions of the original
idea.

“Perversions.” You know, there are ways of making a point that don’t
involve blanket insults of everyone who disagrees with you.

Mr. Manners reminds the Gentle Poster(s) that the early 1980s were,
indeed,
quite perverse…


Phlip


#16

Brian wrote:

I’m new to both rails and MVC, so please correct me if I
misunderstand. But it seems that controllers DO handle user input for
the typical web application. A view helps a user format that input,
but it can’t receive anything. In fact, I could just send an http
request to a rails application before ever interacting with UI. The
controller is what processes this request, consulting models if
necessary. The view isn’t involved until the application tries to
send information back to me.

Regardless of the direction data travels, a controller should dispatch
to the
view or model as soon as possible. For example…

Model.create! params[:model]

That common idiom passes parameters directly into the createe, in
the
model. This might look like a violation of the rule “no view data
leaking into
the model”, where the params[] are indeed CGI Query details wrapped up
in a
convenient package, but note that params[:model] should only contain
data
primitives - strings and strung integers.

In real life coding, actions can get thick. They might need to use lots
of if
statements to triage input, for example. The rule “all biz logic in the
model”
is not a rule, it is a goal. The closer you get to it, and the more
often you
refactor a design towards that goal, the better.


Phlip


#17

Phlip wrote:

Regardless of the direction data travels

travel.

sorry


#18

Jeff S. wrote:

That’s how I was taught MVC, long before I’d heard of Ruby: Models do
some basic checking, but business logic belongs in the controller. That
was the point of the controller; it gave a central place to put business
logic.

Could you cite? It’s flat-out wrong, and a friend of mine seems to have
flubbed
an interview by stating the correct answer.

The Model should store things your boss says, like “client X can handle
Visas
and Mastercards, but client Y can handle only Visas”. Business rules.

Because controllers are busy controlling, you can’t refactor the crap
out of
them, to leverage tricks like inheritance. X could inherit Y, and add
Mastercard
handling. (Please note that’s a contrived example that would not
withstand even
cursory domain-driven analysis!:wink:

Models have only one predefined role - persistence into a database - so
they are
free to otherwise refactor their logic around until it’s DRY. If you
wrote a
non-trivial Rails app without this refactoring and designing, your
controllers
are going to rapidly devolve into unmanageable brambles of tangled
thorny logic…

In a system where the controllers are not so constrained (CGI, Ajax,
HTTP, etc.)
they are free to refactor into more subtle designs. Some projects, using
other
platforms, could conceivably store lots of business rules in objects
that also
control. That still does not mean it’s a good idea.

The Model should be as fat as possible. Anything a user can do to the biz rules,
thru the View, unit test can do to the Model directly.

That’s not necessarily true.

That is extremely necessarily true. Defining designs in terms of how to
test-drive their creation is a simple but powerful way to explain
generic design
guidelines. Think, for example, of the tests required to generate one of
the
designs in the book /Design Patterns/.

When you are writing an application, you should respond to the business
rules in
your requirements by TDDing them into your models first, then wiring
them up to
your Views. There’s simply no counter-example for this practice.

So the question is: Where did this disinformation come from? Do any websites (or

cough< books) out there actually say the biz rules belong in the controller?

I first used MVC with MFC, about 10+ years ago, and in Java shortly
thereafter. Fat controllers may have been advocated by MS back then.

MFC exploits “vendor lock-in” by tempting you with a wizard. I suspect
Rails is
an example of a competing platform that simply doesn’t need one! Beyond
script/generate…


Phlip


#19

Phlip wrote:

Jeff S. wrote:

That’s how I was taught MVC, long before I’d heard of Ruby: Models do
some basic checking, but business logic belongs in the controller. That
was the point of the controller; it gave a central place to put business
logic.

Could you cite?

No; as I say, this was 10+ years ago. Again, I’m not arguing what it
“should be,” nor what it “originally was;” however, I am telling you
that a lot professional engineers, including me, were originally taught
that business logic belonged in controllers. When I first learned of
MVC, I was undergraduate student, not an expert on OOD. I don’t code my
Rails apps with thick Controllers, but I am bothered by this cult-like
adherence to some One True Way of Agile programming. We’re going to end
up with a lot of bad software and lousy developers.

The Model should be as fat as possible. Anything a user can do to the biz rules,
thru the View, unit test can do to the Model directly.
That’s not necessarily true.

That is extremely necessarily true.

“This is widely considered a good idea” != “This is necessarily true”

Defining designs in terms of how to
test-drive their creation is a simple but powerful way to explain generic design
guidelines. Think, for example, of the tests required to generate one of the
designs in the book /Design Patterns/.

Whether TDD is a good idea has nothing to do with how functionality
should be apportioned among Model, View, and Controller. In particular,
Controllers need tests of their own, no matter how much functionality
you stick in the Models. (Unless you’re going for only a Model/View
paradigm, as some would argue Java Swing uses.)

When you are writing an application, you should respond to the business rules in
your requirements by TDDing them into your models first, then wiring them up to
your Views. There’s simply no counter-example for this practice.

I believe you’ve been misled, and that you are mistaken. I’m not sure
how else to say that, nor do I have any interest in arguing with a
zealot who makes such absolutisms.

So the question is: Where did this disinformation come from? Do any websites (or

cough< books) out there actually say the biz rules belong in the controller?
I first used MVC with MFC, about 10+ years ago, and in Java shortly
thereafter. Fat controllers may have been advocated by MS back then.

MFC exploits “vendor lock-in” by tempting you with a wizard. I suspect Rails is
an example of a competing platform that simply doesn’t need one! Beyond
script/generate…

Rails is more “wizard” driven than MFC ever was, with scripts to
generate just about everything. MFC was that way because it was meant
to encourage consistent look and feel among applications; Rails is that
way because it relies heavily on conventions to work properly. If you
really want to pick an “our way or the highway” development framework,
take a look at Cocoa.


#20

Robert W. wrote:

Jeff S. wrote:

take a look at Cocoa.

Which, by the way, is probably the most brilliantly conceived
event-driven MVC framework I’ve ever had the pleasure of using. The very
fact that you play by it’s rules by doing things “it’s way” is much of
what makes it so.

Correction: “its rules” and “its way.” Sorry for the misuse of the
apostrophe.