This is probably my nitpick with people (not all) that come from Rails and tries to 'teach' others about general concepts by the way they are done in Rails.

A good example is "In Programming, Fat Models Are Preferable To Size Zero Models". Sure, if you are in Rails, you probably don't want a 3000 lines controller, but guess what, there are also Services! By moving logic to the Model you end up with fat models that do a lot of things, instead of having specialized Services for logical parts of you application.

badclient example below is a prime example. Do we really want the model to handle authorization? What if it also needs to know about the account the user is trying to access has been suspended (then the User model needs to know about Account model suspension) or even authorization for that specific page (only managers should be able to access payroll).

By moving the logic to the model, you now have a big fat model that needs to know about everything in the application (and most likely, a lot of logic will have to be replicated throughout other models).

About the "Fat Stupid Ugly Controllers" can also be separated to View Presenters, making the code much cleaner (presentation is presentation, controller is controller, model is model) and not Fat Stupid Ugly Models.

Sorry for the rant, but I'm sick and tired Rails programmers talking about Rails ways like it is the one true way while there are a lot of Software Design Practices that are better suited for each case.

He still didn't clear up the conceptual understanding of "model" very well.

The Data Model. Just the data. - pure Value Objects, classes which are little more than wrappers to data, which can be assembled in more complex structures for presentation by a view.

The Domain Model. A representation of the data, the actors, and the processes. The objects are often a mix of pure value objects, object managers, actors that carry out actions on multiple data items, and facades/processes that coordinate several actors, maintain their own state (internal model/statemachine or externally in other objects).

The "Framework Supported" Model (for want of a better term). This is where the data model has some aspects of the domain model, but a number of pieces are defined outside of the "model" and in a framework. Bits that are often separated are things like: validation, keeping track of sessions (actor state), collecting multiple models together for presentation to a view (maybe typically done in a facade), dependency injection, lazy loading, etc.

Personally, if a framework has clean and clear support for things that I'd usually put in a Domain Model, I'm probably going to use it. Especially for input validation!! They usually end up in the "controller" for lack of a better place to put them. However, sometimes it makes sense to pull it into your model... especially where you may have multiple controllers/processes acting on the same data - and leaving it to the framework controller is going to be an issue.

I'm not a fan of "views" pushing data back to the models without the controller... unless you're doing your validation and access controls, etc. in the domain model then it's a slippery slope. That said... if you are tracking state in the model, then the view updating state? That sounds OK... there are no hard and fast rules!

Nice post that would be even nicer if accompanied by some pseudocode examples.

You go on and on about constantly reducing the size of your controllers. I'm sold! I just don't know where to start :(

Let's say I am verifying login. So I have the controller that looks something like this:

Function logincontroller() {

if (model->verify(user,pass)) redirect(validurl) Else Redirect(invalidurl)

}

How can I improve this? Btw my intended syntax was php but left out proper syntax due to iPhone:)

To be honest, these problems are probably more endemic in the Zend Framework world than most other frameworks, since ZF was specifically designed to be a toolbox, not an opinionated framework, and therefor doesn't come with a standard way of implementing models.

Personally I like this because it make ZF usable in a wide range of projects, but I've seen a lot of developers struggle with the concept of having to design the model themselves instead of filling in the blanks in the framework. Nine out of ten times they end up stuffing the business logic inside the controllers because "there's nowhere else to put it".

He had me up until the part about models talking directly to views. I was nodding along until then.

While I agree that the application business logic should be in models, but the controller needs to be that traffic cop, only asking for what the view needs and then handing it to the view. Having the view get this giant dump of things from models, skipping the controller entirely makes for confusing code as views can (and should) be reused for multiple data sets on different pages. The controller doesn't have to have much in it, but it's the traffic cop for the page (like a boss).

YES! I am exhausted from a long run and cannot articulate my thoughts clearly but just as an example, I try and overload my Django models with as much logic as I possibly can. Add tons of functions for fetching attributes, use @property(s) and make use of custom managers or queryset subclassing when you can. If you spend the time to "fatten" (as this article mentions) up your models, your views and the actual nitty-gritty glue holding your app together will be MUCH simpler and easier to follow. Let your models do the heavy lifting!

Interesting reading but I don't get the rant about the controllers being so ugly containing the model logic? I mean it's essentially a matter where you place the logic. The logic itself whether in the controller or model will/could be very similar.

Slightly OT extreme noob question: what is the core idea behind controllers? I've read some introductory Rails stuff but I never really got a good grasp of what the point of the controller is, most explanations seemingly reducing to "the thing that goes between the thinky bit and the user interface". I know I'm missing a lot, can anyone point me in the direction of some good reading material? My background isn't webdev so there's probably some missing assumed knowledge.

Fat Stupid Ugly Controller instead of the succint (decidedly more literate) Fat Controller - sadly an opportunity lost.

I am concerned by the tendancy to throw everything into one in-process model. (by in-process I mean that we are calling a ruby function calculatePrice in the same model / whatever instead of calling out to a web api and getting back a price)   

It's usually cleaner to think about web service calls - not  put everything into same model

even though you can cleanly seperate functions within a single model the tendancy to make an inprocess call not an api call is always high.    So removethe tempation.

Have a thin model, a thin view and a thin controller all doing just one (rest-ful) thing and call between them

the overhead in creating objects from passed in Json is far lower the trying to unstitch logins, transactions, funny bits of business logic from one monolithic model 

(not that I am saying you would end up with a monolithic piece of spagetti but I have seen some indark corners of the enterprise world, even in projects which have all the right buzzwords)

The trouble with this article, and indeed many of the posts in this HN discussion, is that what certain web frameworks have decided to call MVC has only a tenuous relationship to real MVC.

The point of MVC, as originally practised in Smalltalk and used by numerous GUI libraries ever since, is the three-way separation of concerns between the underlying data, the presentation of that data, and interactions that change that data. It's an elegant way to reduce dependencies, in particular eliminating dependencies from the model onto any part of the UI, by having some parts of the system push information and others pull it. It remains a useful basic architecture for interactive GUI applications to this day.

In the modern corruption used by various web frameworks, three subsystems have the same names, and that is about where the similarity ends. The three components are typically arranged in a linear stack, with linear dependencies. The responsibilities for the "controller" are very different.

This leads to comments like the parent post:

    He had me up until the part about models talking directly to views.
    I was nodding along until then. While I agree that the application
    business logic should be in models, but the controller needs to be
    that traffic cop, only asking for what the view needs and then
    handing it to the view.

If your view can't present data from your model without going via a controller, then you simply aren't using MVC. Your design might be perfectly reasonable and do its job well, but please call it something else.

What you're suggesting is more like MVP (Model View Presenter). Making the view "dumb" in MVC simply results in a lot of overhead and duplicate logic inside the controller, that constantly has to "translate" stuff for the view.

Having the view talk directly to the model actually makes the code a lot simpler (and a lot less of it).

If all your view can get from the model is "a giant dump of things", there is probably something missing from the model. Because in that case, all the controller can get is also "a giant dump", which means you will need to add business logic to the controller to process this giant dump for the convenience of the view. Which puts us right back where we started: bloated controllers that contain business logic that should be in the model.