3 ms·

> TDD may not work well for Rails applications is all I've been able to glean from his posts. And even this is not the case - the Ruby/Rails community is heavi

> TDD may not work well for Rails applications is all I've been able to glean from his posts. And even this is not the case - the Ruby/Rails community is heavily involved with TDD/testing frameworks/etc, because it is so easy to do and because unit tests can help bring some of the assurances you miss from static typing back into your systems. The issue DHH has with TDD is, imo, all wrapped up in the issues he has with design patterns, service layers, etc. Doing TDD on a business domain object that subclasses ActiveRecord::Base forces you to mock/stub all sorts of DB calls (which is irritating), which in turn highlights the fact that, contrary to what DHH says, it's not always a very good idea to stick all of your business logic in the model layer. DHH isn't having any of it, but by no means is he representative of the Ruby/Rails community here. (see: https://www.destroyallsoftware.com/screencasts/catalog/what-goes-in-active-records https://www.destroyallsoftware.com/screencasts/catalog/what-... for just one of many examples)

ejstronge 12y ago
Out of curiosity, where could/should business logic go in MVC-ish architectures?
- mbillie1 12y ago
  Normally in the model; but often in Rails the "model" gets conflated with the "persistence layer." Many of us who develop in Rails feel that the persistence layer should have the single responsibility of persistence, and would like to use something like a DAO pattern there, keeping business objects / logic in pure Ruby classes. Note that this is not necessary for small, simple Rails applications: by all means, if you're writing a blog app, stick everything in AR::Base and don't over-design. But once you start working in large-scale, non-trivial Rails apps, it becomes very painful to have to have all of your tests running against your database for example. This is probably something of an idiosyncrasy of Rails, and may have little relevance to other frameworks / languages.
agentultra 12y ago
I really like Gary's videos. I wish I had stopped to meet him at Pycon this year (but I didn't know who he was until after his talk! Derp). Thanks for pointing that out though; I didn't intend to assert dhh's opinion <=> rails community's opinion

ejstronge 12y ago

Out of curiosity, where could/should business logic go in MVC-ish architectures?

mbillie1 12y ago
Normally in the model; but often in Rails the "model" gets conflated with the "persistence layer." Many of us who develop in Rails feel that the persistence layer should have the single responsibility of persistence, and would like to use something like a DAO pattern there, keeping business objects / logic in pure Ruby classes. Note that this is not necessary for small, simple Rails applications: by all means, if you're writing a blog app, stick everything in AR::Base and don't over-design. But once you start working in large-scale, non-trivial Rails apps, it becomes very painful to have to have all of your tests running against your database for example. This is probably something of an idiosyncrasy of Rails, and may have little relevance to other frameworks / languages.

agentultra 12y ago

I really like Gary's videos. I wish I had stopped to meet him at Pycon this year (but I didn't know who he was until after his talk! Derp). Thanks for pointing that out though; I didn't intend to assert dhh's opinion <=> rails community's opinion