Phlip wrote: > 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?
No; as I say, this was 10+ years ago. Again, I'm not arguing what it "should be," nor what it "originally was;" however, I am telling you that a lot professional engineers, including me, were originally taught that business logic belonged in controllers. When I first learned of MVC, I was undergraduate student, not an expert on OOD. I don't code my Rails apps with thick Controllers, but I am bothered by this cult-like adherence to some One True Way of Agile programming. We're going to end up with a lot of bad software and lousy developers. >>> 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. "This is widely considered a good idea" != "This is 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/. Whether TDD is a good idea has nothing to do with how functionality should be apportioned among Model, View, and Controller. In particular, Controllers need tests of their own, no matter how much functionality you stick in the Models. (Unless you're going for only a Model/View paradigm, as some would argue Java Swing uses.) > 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. I believe you've been misled, and that you are mistaken. I'm not sure how else to say that, nor do I have any interest in arguing with a zealot who makes such absolutisms. >>> 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... Rails is more "wizard" driven than MFC ever was, with scripts to generate just about everything. MFC was that way because it was meant to encourage consistent look and feel among applications; Rails is that way because it relies heavily on conventions to work properly. If you really want to pick an "our way or the highway" development framework, take a look at Cocoa. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
