Takie tam pejoracje, które może kogoś zainteresują: https://gist.github.com/paneq/5178264
Moje przemyślenia:
- Kod Andrzeja jest 5 razy bardziej czytelny niż Twój (wiem - u niego nie ma operacji na AR, ale to nie o to chodzi)
- “Listen to your tests” - nie ma sensownego zestawu testów, nie ma kontekstu, trudno stwierdzić, czy to rozwiązanie jest dobre/niedobre.
- Szybkość działania testów można poprawić korzystajac z NullDB
- To do czego stworzono walidacje nie ma zastosowania w tym kontekście. To powinny być obiekty Policy, Processor czy jak tam sobie to nazwiesz (abstrahujące proces przepisywania zadania od jednego uż. do drugiego). Walidacje imho nadają się właśnie wyłącznie do określania niezależnych/lokalnych warunków zapisania obiektu do bazy.
Co nie zmienia faktu, że ostatnio jestem wielkim fanem DI w kontekście Railsów i ogólnie Rubiego. Avdi mnie przekonał, że to jest właściwa droga. Więc w tej kwestii całkowicie Cię popieram.
Zdecydowanie. Kod Andrzej jednak żyje w pewnej próżni, z której on sam zdaje sobie sprawę. Andrzej często zakłada model w którym aplikacja działa całkowicie w pamięci w modelu Prevayler (Java) / Madlein (Ruby) albo też przed requestem instancjujemy sobie na podstawie danych z bazy jakąś część drzewa obiektów, wprawiamy ją w ruch, a następnie na podstawie dokonanych zmian persystujemy je z powrotem na bazę. Tego przed i po często nie pokazuje i o tym się nie dyskutuje. A to nie jest coś co łatwo dodać do Klasycznej Apki Railsowej po kilku latach pracy i testach jednostkowych sięgających kilku minut.
Takie życie przykładów 
Jak przeczytałem sekcję Limitations to jestem sceptyczny…
Świetne stwierdzenie. Szkoda, że to nie jest to co widzę na codzień używane w projektach, którym robię Code Review.
Ah, to fascynujące. Andrzej raczej nie jest fanem tego podejścia Avdiego jakie zaprezentował w Objects on Rails.