Rails - May 2009 - under MVC, business rules belong in the __________

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

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.
-- 
Posted via http://www.ruby-forum.com/.

On Wed, May 27, 2009 at 10:34 AM, Robert Walker
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
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. <G>

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

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.

On Thu, May 28, 2009 at 10:17 AM, Jeff Schwab
<jeff-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org>
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.
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

Rick DeNatale wrote:
> On Thu, May 28, 2009 at 10:17 AM, Jeff Schwab
<jeff-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org> 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.
> 
> 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.

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?



On May 28, 11:29 am, Jeff Schwab
<j...-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org>
wrote:
> Rick DeNatale wrote:
> > On Thu, May 28, 2009 at 10:17 AM, Jeff Schwab
<j...-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org> 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.
>
> > 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.

On May 28, 11:29 am, Jeff Schwab
<j...-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org>
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.

Brian wrote:
> 
> 
> On May 28, 11:29 am, Jeff Schwab
<j...-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org> 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.
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.

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.
> On May 28, 11:29 am, Jeff Schwab
<j...-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org> wrote:
>> Rick DeNatale wrote:
>>> On Thu, May 28, 2009 at 10:17 AM, Jeff Schwab
<j...-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org> 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.
>>> 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.

On Thursday 28 May 2009, Jeff Schwab 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 Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

On Thu, May 28, 2009 at 2:57 PM, Jeff Schwab
<jeff-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org> 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 :-)

-- 
Hassan Schroeder ------------------------
hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Michael Schuerig wrote:
> On Thursday 28 May 2009, Jeff Schwab 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?
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.

On Thu, May 28, 2009 at 11:29 AM, Jeff Schwab
<jeff-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org>
wrote:
>
> Rick DeNatale wrote:
>>  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.
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

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 <form> 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

>>> 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

Jeff Schwab 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!;)

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

Phlip wrote:
> Regardless of the direction data travels
travel.

<voice size=''tiny''> sorry </voice>

Phlip wrote:
> Jeff Schwab 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.

Jeff Schwab 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.
-- 
Posted via http://www.ruby-forum.com/.

Robert Walker wrote:
> Jeff Schwab 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.
-- 
Posted via http://www.ruby-forum.com/.

Robert Walker wrote:
> Jeff Schwab 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.
Mostly agreed.  It''s very much like Rails, or C++ template 
metaprogramming, in the sense that convention is leveraged to define 
program structure.  Restrictions aren''t necessarily a bad thing.  The 
one aspect of Cocoa development that does really bother me is that it''s
only really meant to be done in XCode, with which I am not thrilled.

On May 29, 10:40 am, Jeff Schwab
<j...-0DHsjr3A8/m6BbymS3xAUA@public.gmane.org> wrote:
> program structure.  Restrictions aren''t necessarily a bad thing.
 The
> one aspect of Cocoa development that does really bother me is that
it''s
> only really meant to be done in XCode, with which I am not thrilled.
You can do Cocoa development in any editor you wish to use.  I edit
code in TextMate, and only use Xcode to manage the project overall,
open the xibs in Interface Builder, etc.  It would be easily possible
for anyone else to build an IDE for developing with Cocoa.  The
problem is that Xcode doesn''t suck too bad, and it''s free, so
it would
be difficult to sell another IDE to support the development costs.
Several years ago, Codewarrior supported Cocoa development.  As Xcode
was improved more and more, less and less people bought and upgraded
CW and therefore it eventually went away, unable to compete with
Apple''s free offering.

Cocoa also doesn''t lock you into following strict MVC.  In fact,
it''s
even easier than Rails to merge model logic into the controller.  It''s
also even easier than Rails to end up with what should be view code in
the controller.  In fact, simple apps may end up almost entirely
contained within a single controller if you''re not careful.

Jim

Jeff Schwab wrote:
> Robert Walker wrote:
> Mostly agreed.  It''s very much like Rails, or C++ template
This seems to me to be a gross oversimplification. While there may be 
some similarities, in that they both implement the basic MVC design 
pattern, Cocoa development involves design patterns that are rarely seen 
in Rails, or any other web framework. Patterns such as chain of 
responsibility, decorator/delegation, command, composite/view hierarchy, 
key value code/key value observing.

My only real point here is that any similarities with Rails falls away 
very quickly when you get into the inner workings of the Cocoa 
framework.
> metaprogramming, in the sense that convention is leveraged to define
> program structure.  Restrictions aren''t necessarily a bad thing. 
The
> one aspect of Cocoa development that does really bother me is that
it''s
> only really meant to be done in XCode, with which I am not thrilled.
I do admit that Xcode''s text editor could use some work. However,
I''d
rather use Xcode''s integrated editor over many of the other IDEs
I''ve
used like Eclipse, NetBeans, JDeveloper, etc.

However, as Jim stated, you don''t have to use it. You can use whatever 
editor you want.

The fact is though, that there is much more focus placed on features for 
dealing with the complexities of desktop application development, which 
don''t apply to web based frameworks like Rails. All you really need to 
develop a Rails application is a text editor and a command line. Xcode 
is, by necessity, much more that a simple text editor.
-- 
Posted via http://www.ruby-forum.com/.