PP Junty wrote:
hello. i just checked Chad Fowler's post "20 Rails Development No-No's"
one guideline caught my attention. it says:
"Nothing that looks at all like SQL should go into a controller, view,
Things that "look like" SQL include any kind of query more elaborate than a simple accessor call. For example:
- hit a service that provides realtime currency exchange rates
- hit a service that provides the local weather report
- retweet some popular tweets
- calculate the integral of a Zipfs Law partition over a population
- calculate 40 + 2
- rip a list of items, then .select and .reject its candidates
- parse some XML with XPath and find a data point
it really came as a surprise to me as Rails itself seems to go against
such practice by its AR 'conditions' option, which most of the times
SQL code. like in this example from Rails Cookbook:
Then don't put it in the controller or view - even if the Book does.
There's a super-easy metric to see if you are obeying this rule: How easily can you test your SQL-like statement?
If your test must call a controller with get :action, you are farther from your statement than you should. (But note such a test might call an action and detect that it called the correct model method, so long as such a test case is completely auxiliary to your actual method and its real test!)
Similarly, you should not call a view, render a page, rip its details out of HTML (even with assert_xhtml!), and then test that your SQL-like statement worked.
Put another way, the Law of Demeter should apply more strictly in the controllers and views!