On 4/25/07, Richard C. [email protected] wrote:
want to use in app/models/filesystem.rb
I think you were closer to a good representation the first time: do the
work in the controllers. Or better yet, farm the effort out to controller
helpers or even something global like a plugin.
Ruby’s file processing and directory crawling methods are very powerful,
hiding them under a lot of inappropriate abstraction layers, reimplementing
them as finders etc. just seems like the wrong thing to do. I think you
were right the first time.
I’ve written a lot of ‘heavy’ controllers and think the approach has
some advantages. It’s usually less work than coming up with a domain
layer with a clean/elegant interface, IMO, but it usually ends up
smelling a bit strange.
Imagine what happens if Jonathan wants to do a GUI or CLI -based port
of his app; new presentation layers would require new controllers, and
he’d have to rewrite, or at least copy+paste, his file system code for
Granted, this doesn’t apply to most projects, but i still believe
there’s a maintainability issue.
The model directory is where all your other domain logic is kept, and
I don’t see any fundamental difference between AR backed and non-db
models, so why keep them apart…? If it’s app specific code, it really
doesn’t belong in a library.
You’d also get to unit test your classes easily, which is a big plus in