Thanks Dave, does that mean I'm no longer a novice since I found God? :) Yes I always though I was doing it correctly by putting everything related to say Order into Order. So I assumed that getting an Order list from User should be a method placed inside Order. Then I noticed it expects to get param[:id] as User.id so I was tempted to put it back to User (the God object). How do reckon I solve this Order list problem?
I've been reading a lot about Slim Controller, Fat Model and now looking at my codebase with new lenses but still pretty hard to move stuff into Model. I saw in one Railscast example, Send_password_reset is inside User.rb. Then I went WTF and then soon discovered the Model layer wasn't meant to map database and can hold logic. Right now I still have a lot of UserMailer stuff in my Controller layer. But I see the tunnel light could be from here: - http://stackoverflow.com/questions/14044681/fat-models-and-skinny-controllers-sounds-like-creating-god-models I'm also exploring model scope and Has_Scope gem to reduce the amount of methods in Controller. I'm trying to avoid STI and polymorphism stuff which seems to have me change current_user paths to some weird stuff. And then there is ActiveSupport::Concern to extend the Controller http://stackoverflow.com/questions/18745021/the-best-way-to-split-up-a-large-rails-controller On Monday, March 3, 2014 11:49:31 PM UTC+8, Dave Aronson wrote: > > On Mon, Mar 3, 2014 at 5:36 AM, Colin Law <[email protected] <javascript:>> > wrote: > > > On 3 March 2014 09:18, Brandon <[email protected] <javascript:>> wrote: > ... > >> But it seems that User controller will be pretty FAT over time. > > > > Why? > > Because User has a classic tendency to become a God Object. :-) > > Brandon, sorry if I'm repeating stuff that came earlier, I didn't pay > much attention to this thread until the above exchange caught my eye. > > The User class tends to accumulate a lot of crud (not to be confused > with CRUD), becoming what we call a God Object, one that sees, knows, > and tells all. > > To combat that tendency, remember the Single Responsibility Principle, > and look for clear dividing lines to separate responsibilities. What > I usually do is keep User responsible only for logging in and out, so > it usually contains only username, encrypted password, and (only for > purposes of sending password reset tokens and suchlike) an email > address. Any other personal info, like a "real" name, address, phone > number, biography, picture, etc. goes in a Profile object that > belongs_to that User. Other info for specific aspects of using the > system, like availability and desired salary if it's a job board, go > in more specific profiles, like JobSeekerProfile or JobPosterProfile. > > -Dave > > -- > Dave Aronson, the T. Rex of Codosaurus LLC (www.codosaur.us); > FREELANCE SOFTWARE DEVELOPER, AVAILABLE AS OF MARCH 1st 2014; > creator of Pull Request Roulette, at PullRequestRoulette.com. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9d638dbd-a029-4e20-beb5-c16a8d6e7a92%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
