Comments on: Let Them Code Cake!

By: davidj

davidj — Sat, 14 Jan 2012 21:30:00 +0000

This was a great post it was informative i also agreee AR validations should go in this model. i will subscribe and follow, can’t wait for more!

By: c0lise0

c0lise0 — Fri, 18 Nov 2011 02:24:00 +0000

The cup looks so small next to the box lol =P tricyclic antidepressants

By: Scala: Traits galore at Mark Needham

Scala: Traits galore at Mark Needham — Sat, 09 Jul 2011 19:56:27 +0000

[...] design is starting to resemble the cake layering pattern suggested by Martin Emde as an approach for avoiding ActiveRecord objects becoming cluttered with [...]

By: drboolean

drboolean — Wed, 17 Feb 2010 00:57:58 +0000

Well the indentations didn't work…but oh well.

By: drboolean

drboolean — Wed, 17 Feb 2010 00:56:53 +0000

Hi Aaron, sorry i didn't notice your comment until just now.

Do you guys namespace classes with their owner classes?
I.E.

class Pixar
class Up
end
end

- app
– models
– disney.rb
– pixar
– up.rb
– toystory.rb
– pixar.rb

Here's to hoping this comment's formatting doesn't explode.
(I'm a big fan of other inbox btw)

By: Ryan Hanks

Ryan Hanks — Mon, 15 Feb 2010 15:10:48 +0000

When extracting behavior into a module of an ActiveRecord class as you do in strategy #2, do typically define that module in a different file than the one you are defining the ActiveRecord class in? I'd like to extract the module defining the behavior into a separate file, but I'm struggling with the best way to do so in the context of a rails app while still making the use of autoloading and Textmate's shortcuts that let me jump back and forth between a spec and the subject code. Maybe I should just forget about trying to make use of the default autoloading behavior. Do you have any suggestions?

By: Mark Wilden

Mark Wilden — Fri, 12 Feb 2010 19:38:13 +0000

Validation is necessary whether or not an object is persisted. In Rails, we allow invalid objects primarily for UI purposes: we want to be able to use the object to show the user what was entered that was incorrect.

But in another environment, invalid objects are simply not allowed to be created. This is what the "constructor" is for in languages that have this feature.

In either case, it is necessary to know or guarantee that an in-memory object can be used in the Model layer of the application – even if it vanishes into thin air without being persisted.

By: Craftiness

Craftiness — Fri, 12 Feb 2010 18:00:22 +0000

I agree. But that still violates the Law of Demeter. Isn't 'persisting' data and 'validating' data two reasons to change?

This is nitpick, but I find it a fascinating one. The lines we draw in code organization can sometimes be quite clear. But often, we end up with code that sits in a grey area.

Another principle I apply is Least Surprise. Where would other developers expect this code to be. AR validations should therefore go in the Model.

This was a great post Martin. I hope everything is going well for you in San Francisco!

By: Aaron Scruggs

Aaron Scruggs — Fri, 12 Feb 2010 16:45:22 +0000

At OtherInbox, we actually have a directory named PORO, for just these sort of classes; it has grown huge.

This does seem to lead to an organizational concern. How do you store all of these classes in a way that is intuitive to find what you are looking for and create new ones?

By: shilpa6

shilpa6 — Fri, 12 Feb 2010 06:37:26 +0000

Great article! There's some great prior thinking around domain patterns, and it's easy to cozy up with the "rails blinders" on, eventually winding for worse. Dui Attorney Temecula