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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
