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

Where the logic hides in rails apps

gammons.github.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Where the logic hides in rails apps

#11

Post by moe »

This is the sanest Rails design-advice that I've read in a long time.

It counters the misguided "implicit over explicit"-mantra that is both very prevalent in the rails-community and also the source of most problems.

I.e. when you watch any random RailsCast it is usually filled to the rim with obscure incantations and "look how we need only one LoC to perform $excessive_magic"!

The end-result are those deeply entangled "piles of rails" that we've all seen and suffered from. Hopelessly overloaded models and a dense mesh of hidden interdependencies that nobody grasps anymore because many of them are not even explicitly declared.

Personally I've largely given up hope on rails and am waiting for the successor. The rails-team just seems too fixated on digging their rabbit hole ever deeper, rather than re-visiting design mistakes that were made early on.

However, if you are stuck with a Rails-app for the time being (and who isn't..) I'd definitely recommend to follow a pattern like the one outlined in this post. The best way to use Rails nowadays is to steer clear from most of the entrenched practices and packages (e.g. devise and related trainwrecks) and to use it like a library rather than a framework - as much as that is possible.

This eases the migration to the rails-successor when it manifests, and helps preserve the sanity of your older self and his successor.

Re: Where the logic hides in rails apps

#12

Post by stevewilhelm »

We have been moving the complex logic out of the models into libraries. But we are not happy with this approach.

We also find it difficult to cleanly develop views where data is needed from several different models. The whole Rails REST and MVC model gets in the way.

Would love to hear about how other wiser people have deal with these situations.

Re: Where the logic hides in rails apps

#13

Post by breckenedge »

5vforest wrote: post #6

Maybe this is naive, but what's wrong with just putting `UserMailer.welcome_email(user).deliver` in the controller, right after the user is created? In my mind, delegating an email to be sent should be a job for the controller. IIRC, the Rails ideology says that "Models should not know about any part of the application except for their own datastore." Even though the :after_create hook is the "Rails way", doesn't thi…

I like it too, and have this line of code in a few apps. It's not technically right because, in MVC, your business logic belongs in your models.

Imagine a situation where you want to bulk-create Users via script (or, simply, not via your controller "create" action). Shouldn't those bulk-created users get emails too? It depends on your business logic, hence, your model.

Re: Where the logic hides in rails apps

#14

Post by 5vforest »

moe wrote: post #11

This is the sanest Rails design-advice that I've read in a long time. It counters the misguided "implicit over explicit"-mantra that is both very prevalent in the rails-community and also the source of most problems. I.e. when you watch any random RailsCast it is usually filled to the rim with obscure incantations and "look how we need only one LoC to perform $excessive_magic"! The end-result are those deeply entangl…

I agree, although I'd add that the "magic" can be both the best and the worst part of Rails.

The "magic" is what makes Rails extremely fast to prototype with. For me, at least, it's what makes working with Rails fun, since it lets you spend time writing application code instead of repetitive business logic.

It's also what leads a less-experienced developer to get in over their head quite quickly. My only problem with programs like Dev Bootcamp is that complete newbies shouldn't be learning Rails, they should first be building an application with a much-less robust framework so that they truly appreciate (and are wary of) how much "magic" is in a framework like Rails.

As a side note, if you haven't done so already, take a look at express for node.js. You say you're "waiting for the successor", and it seems like you want something less all-encompassing than Rails.

Re: Where the logic hides in rails apps

#15

Post by FuzzyDunlop »

0x0 wrote: post #2

These kinds of callbacks, which remind me about the "aspect oriented programming" that was hyped for a short while a few years ago, look super dangerous. I could easily imagine someone unaware of this hook running a test to create a bunch of user entries, sending emails all over the place without even realizing. It's like someone read http://en.wikipedia.org/wiki/COMEFROM and took it seriously.

If using Rails, then by default the environment specific config will (I believe) print emails to the log instead of actually sending them.

Re: Where the logic hides in rails apps

#16

Post by lucaspiller »

LaGrange wrote: post #9
5vforest wrote: post #6

Maybe this is naive, but what's wrong with just putting `UserMailer.welcome_email(user).deliver` in the controller, right after the user is created? In my mind, delegating an email to be sent should be a job for the controller. IIRC, the Rails ideology says that "Models should not know about any part of the application except for their own datastore." Even though the :after_create hook is the "Rails way", doesn't thi…

It's okay if that's the only case where the email should be sent, and other means of user creations should never, ever do that. It might be an issue if, for example, the email should be sent always, no matter how the user was created. Edit: basically, the question is "which process involves sending the email". It might be "creating a user," or it might be "using the 'create user' form". At some point you might need a…

We had a case at work for not doing this. We had a section of our app where users could set up their profile, for example /user/profile (scoped to them by their session). Imagine it is more than just CRUD, and has a few bits of complicated logic (in reality there are multiple controllers - it's a big profile :D).

We then wanted to add the ability for admins to edit profiles, so we created /admin/users/[id]/profile. If the logic wasn't in the model we would have to repeat it in both controllers (the views can easily be reused by having the form elements in partials).

Re: Where the logic hides in rails apps

#17

Post by LaGrange »

lucaspiller wrote: post #16
LaGrange wrote: post #9

Earlier quoted context omitted.

It's okay if that's the only case where the email should be sent, and other means of user creations should never, ever do that. It might be an issue if, for example, the email should be sent always, no matter how the user was created. Edit: basically, the question is "which process involves sending the email". It might be "creating a user," or it might be "using the 'create user' form". At some point you might need a…

We had a case at work for not doing this. We had a section of our app where users could set up their profile, for example /user/profile (scoped to them by their session). Imagine it is more than just CRUD, and has a few bits of complicated logic (in reality there are multiple controllers - it's a big profile :D). We then wanted to add the ability for admins to edit profiles, so we created /admin/users/[id]/profile. I…

Of course — complicated logic is a good hint that code maybe should be moved somewhere else, be it the model or some manager class. Just like you moved (or maybe had from the start) the form elements into partials. It's probably not something to obsess about too early.

The thing that bugs me the most is how both the article and some responses here go into heavy absolutes. Different domains have different needs, and what is "readable" changes between them, not just by size, but by shape as well. And yes, shape and size might change as the app lives (my current codebase being a great example), but you can't really predict everything.

Re: Where the logic hides in rails apps

#18

Post by hayksaakian »

The author seems to contradict himself.

First he claims that sending an email after user creation is conventionally done in the model. Then in his hypothetical scenario a new dev comes in and looks at the controller to discern that same logic.

He completely misses the point, if its conventional to put the welcome email logic in the model then we can expect the new dev to look for the logic in the model.

The whole point of rails is convention above all.

Re: Where the logic hides in rails apps

#19

Post by inancgumus »

graywh wrote: post #5

Avdi Grimm has a "book" on separating business logic from Rails - http://objectsonrails.com/

Yes, I bought the book earlier, although it contains some valuable things but it needs an editorial review. It shows kind of things wich not simple, just complex (I said simple, not easy).
Post reply on HN