>
> One of the projects that I'm working on creates and twiddles with a lot
> of directories. In version 1, I did this all in the controllers, but
> I'm beginning to think that the whole design would be cleaner in v2 if I
> made the filesystem a model.
> My plan for going about this would be to generate a model (Filesystem),
> but create no migration for it, and then override all of the methods I'd
> want to use in app/models/filesystem.rb
> All of the directories are directly related to another model, so it'd
> just be passing :id into the model functions. (unlock_dir, lock_dir,
> create, destroy, etc)
> Does this seem like a stupid solution? Is there a much better way that
> I'm missing?
Well I think you might be abusing the abstraction. It might work, maybe
somebody has already implemented something similar successfully.
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
each environment.
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 my book.
Regards,
Isak