Where the logic hides in rails apps • Hacker News Board

Re: Where the logic hides in rails apps

#21

Post by inancgumus » Sun, Dec 23, 2012, 9:13 PM UTC

stevewilhelm wrote: post #12

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.

I think what you are in need is nothing to do with model separation. But, you need to be careful about which code belongs to your business logic. For the views you mentioned, I don't know your code but I think you may use something interim, like a presenter code which takes data from the models and helps views to show it.

Re: Where the logic hides in rails apps

#22

Post by julian37 » Sun, Dec 23, 2012, 9:36 PM UTC

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…

steer clear from most of the entrenched practices and packages (e.g. devise and related trainwrecks)

I agree with your sentiment in general, but what do you suggest to use in place of devise? Surely you're not suggesting to write all the code for handling mail confirmation, password changes etc. yourself?

Re: Where the logic hides in rails apps

#23

Post by codewright » Sun, Dec 23, 2012, 9:58 PM UTC

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 think Rails developers made some deal with the devil where every line of code they write makes them more his dark Servant in exchange for the ability to write Ruby code. (They rarely know any others. Shoulda negotiated for some Erlang.)

Thereby, they seek to write as few lines of code as possible, at the expense of the sanity of everyone else.

Furthering the goals of the dark one all along...

Re: Where the logic hides in rails apps

#24

Post by lobo_tuerto » Sun, Dec 23, 2012, 10:03 PM UTC

julian37 wrote: post #22

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…

steer clear from most of the entrenched practices and packages (e.g. devise and related trainwrecks) I agree with your sentiment in general, but what do you suggest to use in place of devise? Surely you're not suggesting to write all the code for handling mail confirmation, password changes etc. yourself?

Check Authlogic out, it is clean, easy to grasp sourcecode, maybe the closest to implementing it all yourself in the simplest way posible:

  https://github.com/binarylogic/authlogic

Re: Where the logic hides in rails apps

#25

Post by dgregd » Sun, Dec 23, 2012, 10:10 PM UTC

LaGrange wrote: post #7

I'll give a proposal now: every chair of every developer shall from now on give them electric shock whenever they use the term "business logic". Ouch. Seriously, "CreatesContact" is not really a class. It's a procedure, function with side effects, whatever you call it. Just with a class wrapper that boosts the developer ego almost as much as an AbstractFactoryManagerFactory. No, modules are actually great. If you hav…

> give them electric shock

even better, force them to use COmmon Business Oriented Language

Re: Where the logic hides in rails apps

#26

Post by 0x0 » Sun, Dec 23, 2012, 10:12 PM UTC

inancgumus wrote: post #21

stevewilhelm wrote: post #12

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.

I think what you are in need is nothing to do with model separation. But, you need to be careful about which code belongs to your business logic. For the views you mentioned, I don't know your code but I think you may use something interim, like a presenter code which takes data from the models and helps views to show it.

> something interim, like a presenter code which takes data from the models and helps views to show it

..something like a "controller"? :P

Re: Where the logic hides in rails apps

#27

Post by cbrauchli » Sun, Dec 23, 2012, 10:18 PM UTC

julian37 wrote: post #22

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…

steer clear from most of the entrenched practices and packages (e.g. devise and related trainwrecks) I agree with your sentiment in general, but what do you suggest to use in place of devise? Surely you're not suggesting to write all the code for handling mail confirmation, password changes etc. yourself?

I like Sorcery. https://github.com/NoamB/sorcery It calls itself magical, but it is very easy to wrap your head around and override default behaviors if needed.

Re: Where the logic hides in rails apps

#28

Post by moe » Sun, Dec 23, 2012, 10:23 PM UTC

julian37 wrote: post #22

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…

steer clear from most of the entrenched practices and packages (e.g. devise and related trainwrecks) I agree with your sentiment in general, but what do you suggest to use in place of devise? Surely you're not suggesting to write all the code for handling mail confirmation, password changes etc. yourself?

In fact for serious apps that are expected to grow I do recommend to write the auth yourself. It's not a lot of code, from the second time it's mostly copy/paste, and most importantly you'll fully understand what your code does and when, there will be no guesswork in one of the most important areas of your app.

Furthermore you usually end up heavily customizing whatever auth-code you start with anyway. The shrinkwrapped gems never cover even half of what an app eventually needs. Thus another advantage is that you won't have to reverse engineer devise or authlogic when you arrive at that point (and trust me, you really don't want to look at their code and the SQL they emit).

That all said, in a recent project I've found the 'sorcery'-gem to provide a reasonable baseline for rolling your own. It's one of the first "second generation" Rails-gems that refrain from most of the magic and instead provide a set of primitives that you wire up yourself.

It still suffers from a bit of rails-smell (code-generators...), but overall the level of abstraction looks about right.

Re: Where the logic hides in rails apps

#29

Post by tenderlove » Sun, Dec 23, 2012, 10:30 PM UTC

dgregd wrote: post #25

LaGrange wrote: post #7

I'll give a proposal now: every chair of every developer shall from now on give them electric shock whenever they use the term "business logic". Ouch. Seriously, "CreatesContact" is not really a class. It's a procedure, function with side effects, whatever you call it. Just with a class wrapper that boosts the developer ego almost as much as an AbstractFactoryManagerFactory. No, modules are actually great. If you hav…

> give them electric shock even better, force them to use COmmon Business Oriented Language

They should also use principles from the Object Management Group.

Re: Where the logic hides in rails apps

#30

Post by rurounijones » Sun, Dec 23, 2012, 10:43 PM UTC

Anyone intersted in this style of programming needs to read "Clean Ruby" by Jim Gay. (Currently being written with beta access)

To be honest; it looks like this post might have been inspired by that book (or the concepts behind it) but I think the book does a better job explaining it (Obviously, a book vs a single blog post.)