The M in MVC: Why Models are Misunderstood and Unappreciated

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.<p>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.<p>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).<p>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).<p>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.<p>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.<p>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.<p>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).<p>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: <i>validation</i>, 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.<p>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.<p>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.<p>You go on and on about constantly reducing the size of your controllers. I'm sold! I just don't know where to start :(<p>Let's say I am verifying login. So I have the controller that looks something like this:<p>Function logincontroller() {<p>if (model-&#62;verify(user,pass)) redirect(validurl) Else Redirect(invalidurl)<p>}<p>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.<p>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.<p>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)   <p>It's usually cleaner to think about web service calls - not  put everything into same model<p>even though you <i>can</i> cleanly seperate functions within a single model the tendancy to make an inprocess call not an api call is always high.    So removethe tempation.<p>Have a thin model, a thin view and a thin controller all doing just one (rest-ful) thing and call between them<p>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 <p>(not that I am saying <i>you</i> 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)