This is what my User/Create looks like after rethinking my controller. Does
it need more work to make it slimmer?
Basically current_order_id and current_follow_id returns Session values
from Application Controller. Basically site visitors can click place an
order or follow someone and then after that they create their account as
follows. I used CanCan so the loading and authorization is taken care of.
def create
user.updating_password = true
if user.save
sign_in user
if current_order_id.present?
order = Order.find(current_order_id)
order.link_user(user)
elsif current_follow_id.present?
other_user = User.find(current_follow_id)
user.follow_mutually(other_user)
elsif user.membership_plan.present?
UserMailer.plan_registered_notify_admin(user).deliver
else
UserMailer.client_registered_notify_admin(user).deliver
end
redirect_back_or root_url, flash => { :success => 'Welcome!' }
else
render 'new'
end
end
On Tuesday, March 4, 2014 3:26:43 AM UTC+8, Dave Aronson wrote:
>
> On Mon, Mar 3, 2014 at 11:14 AM, Brandon <[email protected] <javascript:>>
> wrote:
>
> > So I assumed that getting an Order list from User
> > should be a method placed inside Order.
>
> Not necessarily, though it will have to interact with Order at some
> point. Getting a User's Orders should be as simple as user.orders,
> assuming orders belong_to users.
>
> > Then I noticed it expects to get param[:id] as User.id
>
> Things like this are usually changeable.
>
> > so I was tempted to put it back to User (the God
> > object). How do reckon I solve this Order list problem?
>
> IIRC you were after a list of users who have ordered, right? The
> immediately obvious solution would be something like "User.all.select
> { |u| u.orders.any? }", but that would have horrible performance as it
> would fetch the orders for each user in a separate query (N+1
> problem). Better would be "User.where(id:
> Order.pluck(:user_id).uniq)", which would do one query to get the IDs
> and one to turn them into users. There's probably also some AR syntax
> to have the DB do the uniq'ing for you, without stooping to
> hand-rolled SQL, but I forget it offhand.
>
> > I've been reading a lot about Slim Controller, Fat Model and now looking
> at
> > my codebase with new lenses
>
> Here, let me grind down those lenses a bit more. :-) The models
> shouldn't be horribly fat either, it's just that it's a *better* place
> for business logic than the controller, never mind the view. If a
> model is getting unwieldy, you can possibly extract a service object,
> or a data object, or some other thing, from it. Let the Single
> Responsibility Principle be your guide.
>
> -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/9baafb80-214b-44c6-913f-d11aabcda44a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
