4 ms·

The funny thing about the argument that people have about where logic should go in an application (models, controllers, or separate objects) is that everyone as

The funny thing about the argument that people have about where logic should go in an application (models, controllers, or separate objects) is that everyone assumes that there is one right answer for an application for all time. We should probably move toward guidance like: "this is when you move your logic here" and "when this happens, it's time to move it out of the controller." For what it's worth, I think it is okay to start doing things the naive way in Rails as long as you know when to refactor toward a different scheme. The bad thing is that it is usually earlier than you think.

dlisboa 14y ago
I don't think everyone assumes that at all. Most discussions on DCI have been about "in big applications, this would work better" instead of "you should do this every time". Some of the supposed benefits aren't even seen in smaller chunks of code. Discussions on modules and SRP have not been absolutist either. People have said things akin to your last paragraph: for simple projects there's nothing really wrong with the normal approach. The problem starts when it grows. The whole "movement" of Rails refactoring only began after people started having trouble moving large codebases around. The guidance thing would be interesting. A collection of situations when things start to go weary, code smells. The thing is you can't do "when this happens, do this" because the "do this" part is the many solutions people have proposed. However I think people have those code smells a bit down already and generally know what a controller should look like. The placement and structure of the domain logic is what is bugging.
programminggeek 14y ago
I think part of the problem is that if you start with the naive way, you get some bad habits and start looking at your code through the lens of ActiveRecord - fat models, persistence, concerns, etc. If your models were just plain ruby objects that validate your data for you, your code is able to do more interesting things - like multiple persistence mechanisms, multiple delivery mechanisms. Oh and they can be incredibly fast to test from day one. If you use a tool like Obvious (which I wrote), you can TDD from day one and still build things fast, while maintaining a good structure.
calinet6 14y ago
Bingo. Having 80 files to move logic out of the controller because of 'design principle' is almost worse than having that code in the controller in the first place. Apply based on reality, balance based on your needs. No articles or dogma required.
joevandyk 14y ago
Do people have these sorts of arguments in languages like clojure or haskell?
- michaelfeathers 14y ago
  Domain matters more than language for this sort of thing. People tend to have these arguments around business applications.

dlisboa 14y ago

I don't think everyone assumes that at all. Most discussions on DCI have been about "in big applications, this would work better" instead of "you should do this every time". Some of the supposed benefits aren't even seen in smaller chunks of code. Discussions on modules and SRP have not been absolutist either. People have said things akin to your last paragraph: for simple projects there's nothing really wrong with the normal approach. The problem starts when it grows. The whole "movement" of Rails refactoring only began after people started having trouble moving large codebases around. The guidance thing would be interesting. A collection of situations when things start to go weary, code smells. The thing is you can't do "when this happens, do this" because the "do this" part is the many solutions people have proposed. However I think people have those code smells a bit down already and generally know what a controller should look like. The placement and structure of the domain logic is what is bugging.

programminggeek 14y ago

I think part of the problem is that if you start with the naive way, you get some bad habits and start looking at your code through the lens of ActiveRecord - fat models, persistence, concerns, etc. If your models were just plain ruby objects that validate your data for you, your code is able to do more interesting things - like multiple persistence mechanisms, multiple delivery mechanisms. Oh and they can be incredibly fast to test from day one. If you use a tool like Obvious (which I wrote), you can TDD from day one and still build things fast, while maintaining a good structure.

calinet6 14y ago

Bingo. Having 80 files to move logic out of the controller because of 'design principle' is almost worse than having that code in the controller in the first place. Apply based on reality, balance based on your needs. No articles or dogma required.

joevandyk 14y ago

Do people have these sorts of arguments in languages like clojure or haskell?

michaelfeathers 14y ago
Domain matters more than language for this sort of thing. People tend to have these arguments around business applications.