[BSousa]

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.

[mattmanser]

I don't use Ruby, I do use MVC (C# in my case). I honestly don't agree with your interpretation of 'MVC'.

[BSousa]

It wasn't an interpretation of MVC per-se but more of what I think the Model in any architecture should be. The Model can be used in MVVM and MVP as well and can be part of DDD way of doing things.

And again, for me, a model should be a representation of an object/data. If it is tied to an ORM (Active Record or Entity Framework) it may come with DB access, but I still don't think models should contain application specific logic. That's what the 'Business' layer should be for. If an Invoice model knows about tax codes from 130 different countries, again I think it knows way too much about the application.

[jawher]

As I see it, the Model in MVC is everything that is not C or V. It encompasses the service layer, the DAOs, the data objects and what have you.

The term Model on it's own doesn't mean much, and is very overloaded with meaning. You can see it as the data objects (stuff like Person(id, firstName, lastName) for example), but that's one definition of it.

[mattmanser]

Seriously, you've got it very wrong. A model is not 'a representation of an object/data'. It's the whole business domain. MVC is about separation of the UI from the domain and the controllers' the intermediary.

Not sure which pattern you're thinking of, but it's not MVC.

[Volpe]

a service could be modelled as a 'model'. That controllers (and other models) use.

This fits both generic 'MVC' practice, AND Rails MVC (if you think they are different...)