Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails – The Missing Parts

eng.joingrouper.com

Post reply on HN
Print view View original

31–40 of 173 posts

Re: Rails – The Missing Parts

#31

Post by nthj »

Legion wrote: post #26
troels wrote: post #14

One thing I can't figure out is whether to place my service objects under `/app/models` or under `/lib`. There doesn't seem to be a clear consensus on this? I tend more towards the former, because autoload works better during development. Also, I consider them part of my domain model. What do you do?

/app/interactors It's a trivial thing to add new folders like this to autoloading: # add to application.rb config.autoload_paths += %W(#{config.root}/app/interactors)

As of Rails 3.0, I believe app/anything/ is autoloaded:

* https://github.com/rails/rails/blob/3-0-stable/railties/test...

* http://hakunin.com/rails3-load-paths

Re: Rails – The Missing Parts

#32

Post by nwienert »

I've found a happy balance developing with rails by adding two strategies:

1) Use presenters for display-only logic to keep controllers concerned with managing requests only.

2) Using service object / custom classes in /lib for actions on models as well as abstracting any common related functionality. Creators, Updaters, Processors, Orchestrators, etc. Keep your models only concerned with data and not data transformation, and your controllers from doing it as well.

Re: Rails – The Missing Parts

#34

Post by dhh »

seancoleman wrote: post #21

A good litmus test of an experienced Rails developer is how large their /lib directories are in relation to project sizes.

By this I hope you mean that the smaller it is, the better.

/lib is intended for non-app specific code. The halfway house before code is extracted into either a Rails PR or a separate gem.

Re: Rails – The Missing Parts

#36

Post by tomblomfield »

tzaman wrote: post #7

We tried using DHH's concerns in place for interactors, but ditched them for PORO/service objects because they can be tested outside Rails.

Yeah - I feel like concerns are a bit of an anti-pattern, especially as they're normally used in Rails.

You've got a God class that exposes 500+ public methods, so you split it into concerns. But now you've still got a God class with 500 methods that's split across 10 files. Good luck understanding that.

Concerns are useful when they're genuinely sharing functionality between classes - not just for splitting up "Big Bags O' Methods".

Re: Rails – The Missing Parts

#37

Post by tomblomfield »

nwienert wrote: post #32

I've found a happy balance developing with rails by adding two strategies: 1) Use presenters for display-only logic to keep controllers concerned with managing requests only. 2) Using service object / custom classes in /lib for actions on models as well as abstracting any common related functionality. Creators, Updaters, Processors, Orchestrators, etc. Keep your models only concerned with data and not data transforma…

Yes, definitely.

One of the future posts (coming soon!) will be on Presenters / Decorators.

I would argue these custom classes should still live in /app, rather than /lib, but I may be wrong.

Re: Rails – The Missing Parts

#39

Post by dhh »

The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by being extracted and wrapped. I would indeed have kept all this in the controller.

The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signup model. Or if you for some reason need to reuse the behavior.

But if all your controllers look like this, with one "interactor" model per action, you're doing it wrong.

Whatever floats your boat, though. If this is what you prefer, great. But please hold the "beginner's version" crap. Plenty of large apps are built with vanilla Rails. Basecamp is one.

Post reply on HN