I'm starting a test spike for a small Rails project, that doesn't have
any database backend. It's some kind of a (Debian Linux) system
administration utility like webmin, that collects and displays system
informations, modifies config files at different locations and runs
system tasks like the installation of Debian packages.
I'm not sure yet, if Rails is the right tool for this, but that's what I
want to figure out. Even if I don't need any of the ActiveRecord stuff,
ActionController, the rhtml-template's, rjs and so on seem to be
useful enought to give Rails a try.
At this point I managed to make the unit tests work without a database
and have coded some simple controllers. But as it now becomes a little
bit more complex, a few questions came up:
1. I'm not using a database, so whenever I use some kind of model
class, I simply don't derive it from ActiveRecord. Such a model e.g. is
"DebianPackage", which holds package information that were retrieved from
the Debian system. The question now is, does this class still belongs
to app/model/ ? Or should non-DB backed models always go to lib/ ?
2. I have some classes that do stuff like retrieving cpu load info from
the system. These classes are some kind of service objects, not models
or controllers. Should they be put into lib/ or somewhere else?
3. If I put the service object classes in lib/, where should the tests
for it go? Am I free to simply put them into test/ or test/services and
create a rake task for it? Unfortunately this at least seems not to be
supported by ZenTest/autotest out of the box.
I'm starting a test spike for a small Rails project, that doesn't have
any database backend. It's some kind of a (Debian Linux) system
administration utility like webmin, that collects and displays system
informations, modifies config files at different locations and runs
system tasks like the installation of Debian packages.
I'm not sure yet, if Rails is the right tool for this, but that's what I
want to figure out. Even if I don't need any of the ActiveRecord stuff,
ActionController, the rhtml-template's, rjs and so on seem to be
useful enought to give Rails a try.
At this point I managed to make the unit tests work without a database
and have coded some simple controllers. But as it now becomes a little
bit more complex, a few questions came up:
1. I'm not using a database, so whenever I use some kind of model
class, I simply don't derive it from ActiveRecord. Such a model e.g. is
"DebianPackage", which holds package information that were retrieved from
the Debian system. The question now is, does this class still belongs
to app/model/ ? Or should non-DB backed models always go to lib/ ?
A model is a model, whether it uses AR or not. Put it in app/model.
2. I have some classes that do stuff like retrieving cpu load info from
the system. These classes are some kind of service objects, not models
or controllers. Should they be put into lib/ or somewhere else?
Lib is fine, though you could also have a "model" called CPU that then
has the smarts underneath to do things like grabbing cpu load and the
like.
3. If I put the service object classes in lib/, where should the tests
for it go? Am I free to simply put them into test/ or test/services and
create a rake task for it? Unfortunately this at least seems not to be
supported by ZenTest/autotest out of the box.
They can go either in /test/unit or /lib/test - I have a little hack I
use for /lib/test here:
Note that was an older version of autotest, but it should work in the
latest version w/o too much trouble.
it says: lib = "... Often non-DB-backed models should be put here."
Lib is fine, though you could also have a "model" called CPU that then
has the smarts underneath to do things like grabbing cpu load and the
like.
Right, the CPU wasn't the best example. What I had in mind was more
something like a class "Dpkg" that wraps the Debian package tools and
has methods like get_available_packages() which returns a list of
"DebianPackage". DebianPackage would be the "model" and Dpkg the service
responsible for providing instances of the model.
