On Tue, Jan 1, 2013 at 5:28 AM, [email protected] wrote:
The problem is that once you dive in, all of the “cool” rails scoping
(user.books.create…) fails and you start managing the relationships
yourself (user.books << book.find_or_create). It feels “wrong”, but as I’m
diving in deeper it seems like the best solution is to create an
intermediate class to handle the association management and keep the logic
out of the controllers.
What’s wrong with “@user.favorite_books <<
Book.find_or_create_by_title(@title)”? That’s still some pretty
“cool” Rails scoping. Compared to what you’d have to do in raw SQL,
it saves you tons of work, and is still very clear. Sure it’s not as
simple as “@user.favorite_books.create @title”, but hey, if you’ve got
more needs, such as non-duplication, often you need to write more
code, and in this case the difference is still small.
Seems to me that “BookListManager.add_to_favorites_for @user, @title”
isn’t any better than that. It just adds one more layer of
indirection, one more place to have to go look to find out what’s
happening. Of course the “enterprisey” lovers of huge ER diagrams
would advocate for that approach (complete with a separate interface
class for it to implement), but they can just go pound Java.
Dave A., the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.