Uwe,
I'm still pretty new to Rails but I can tell you what I do.
I put *all* my business logic under app/models. I consider this the
root of my domain model. For domain modeling I'm a fan of the book
'Domain Driven Design' by Eric Evans. He provides a good taxonomy of
business objects. The main types I use in Rails apps are entities
(extend ActiveRecord::Base, have identity and map to a table), values
objects (aggregates), and policies (strategy or business rule classes
that entities and value objects delegate to). However Evans recommends
packaging the domain model based on natural divisions in the domain, not
technical divisions. So I *might* have something like this:
app/models/sales
app/models/inventory
But *not* something like this:
app/models/entities # sales and inventory entities
app/models/valueobjects # sales and inventory value objects
app/models/policies # sales and inventory policies
I think the structure and layout of the domain model should reflect the
business domain, so I don't like putting business objects under lib. I
reserve lib for technical utility type methods or extensions that might
be useful in other projects -- the kind of stuff that Rails puts in
ActiveSupport.
But to be honest though none of my Rails projects have been that big. I
started to create sub-directories under models like sales, inventory,
using Modules to split the names space. (Just like packages in Java.)
But I decided that for my project that was overkill and I yanked it out.
Coming from Java, I actually like the fact that you can put many classes
in one file in Ruby. It encourages you to create little classes.
Sometimes in Java I wouldn't create a sub-class just because of the
psychological resistance to creating a new file. Or I'd create static
inner classes, which is a tad ugly.
But I agree standards can be good. I'm just glad that in Ruby they're
not built into the language. That's too inflexible!
Steve
P.S.
I keep speaking of my Java experience in the past tense. I wish! Time
to get back to my day job, coding in Java!
Steve
···
-----Original Message-----
From: Uwe Kubosch [mailto:uwe@kubosch.no]
Sent: Wednesday, April 19, 2006 8:44 AM
To: ruby-talk ML
Subject: Organizing Ruby code
Hi all!
I have now completed two web projects using Ruby On Rails in The Real
World and I am very happy about it. Woohoo to me!
In RoR all the components have been assigned a location in the project
tree and I find this very helpful.
I am looking for conventions for how to organize business logic that
does not fit easily into the model-view-controller categories.
I guess this is code that goes into the "lib" directory, and it should
be organized like any Ruby code. The problem is, I have not found any
conventions for how to organize regular Ruby code.
In Java I am forced to have one class per file, the file must be called
the same as the class, and the file should be placed in a directory with
the same name as the package of the class. These limitations are of
enormous help since it makes finding everything very easy.
Is there something similar for Ruby code? Should I use modules where I
use packages in Java? Is there a relationship between module names and
file location? How many classes per file? How many modules per file?
Any tips on how to organize Ruby code is appreciated. I am looking for
a common convention, so that if I follow it, the next Ruby programmer
that comes into the project immediately knows where to find all the
components.
Recommendations for books and websites are always welcome, and so are
any other good sources for information. On the Ruby/Rails topic I have
read the Pickaxe book, Ruby in a Nutshell, and Agile Programming In Ruby
On Rails.
Any comments on this are appreciated.
Uwe Kubosch