MVC Model Is a ViewModel

Confirmation below that the "model" in the MVC world is not a place for business logic:

http://code.tutsplus.com/tutorials/how-to-write-code-that-embraces-change--net-29716

Our models should be "request models", i.e. dumb data objects used for passing information from MVC to the business logic. Optionally, I see no problem including input validation in the models, but nothing more. Business logic should not be in the models.

A Rule of Thumb for Cohesion

from http://code.tutsplus.com/tutorials/how-to-write-code-that-embraces-change--net-29716

You can think of ISP as a higher-level cohesion principle.
When both UI classes depended on the Broker interface, they were similar to two classes, each having four fields, of which two were used in a method and the other two in another method. The class would have not been very cohesive.

Getters/Setters is Fine-Grained Interface is good OOP?

Martin Fowler seems to agree with this notion by mentioning all three in the same breath in an article on the disadvantages of distributing objects.

from http://www.drdobbs.com/errant-architectures/184414966

A local interface is best as a fine-grained interface. Thus, if I have an address class, a good interface will have separate methods for getting the city, getting the state, setting the city, setting the state and so forth. A fine-grained interface is good because it follows the general OO principle of lots of little pieces that can be combined and overridden in various ways to extend the design into the future.