What is a good practice for storing additional classes

Rails
1

My Rails application also contains classes which are independent from
the Rails framework, in that they could be reused unchanged if I would,
for example, created a non-web-based, command-line version of my app.
Such a class could be one which implements business logic, or a simple
utility class.

The question is: What is a good practice of integrating it?

In a “non-Rails” application, I would create a directory app/lib and put
the rb files there. I would ensure, that RUBYLIB points to this
directory, and I would do a “require” in those files where the classes
are needed.

This should also work within Rails. However, is this good practice? How
are experienced Rails developers handle this?

Note also, that these classes will be instantiated only inside a
controller, not in a view or model.

2

Ronald F. wrote in post #1150799:

My Rails application also contains classes which are independent from
the Rails framework, in that they could be reused unchanged if I would,
for example, created a non-web-based, command-line version of my app.
Such a class could be one which implements business logic, or a simple
utility class.

The question is: What is a good practice of integrating it?

In a “non-Rails” application, I would create a directory app/lib and put
the rb files there. I would ensure, that RUBYLIB points to this
directory, and I would do a “require” in those files where the classes
are needed.

This should also work within Rails. However, is this good practice? How
are experienced Rails developers handle this?

Note also, that these classes will be instantiated only inside a
controller, not in a view or model.

Ruby has a mechanism for this. They are called “gems”, libraries of
shared code. Rails provides a “lib” directory for code more tightly
coupled with the application in which they are used. If you do have
model classes that are not subclasses of ActiveRecord there’s still no
reason they can’t live inside the models directory along side your
ActiveRecord subclasses.

Ruby also provides modules and mix-ins for adding functionality to
existing classes, this can often be a good way to implement utility
methods.

3

Robert W. wrote in post #1150810:

Ruby has a mechanism for this. They are called “gems”, libraries of
shared code.

So you are suggesting to write a gem for this??? I would have not
expected this suggestion, but I will think about it.

Rails provides a “lib” directory for code more tightly
coupled with the application in which they are used.

I have noticed the lib directory, but I was a bit reluctant to use it,
because - if I understand it right - whenever I change something in a
file below lib, I would have to restart the rails server, which is
inconvenient during development.

If you do have
model classes that are not subclasses of ActiveRecord there’s still no
reason they can’t live inside the models directory along side your
ActiveRecord subclasses.

Shouldn’t there (in models) be only classes related to - well -
“modelling”, i.e. related to a data model? For example, if I have a
class which represents a connection to separate processes (say, a proxy
to a Clearcase server), this wouldn’t fit well to the other stuff in the
model directory.

Ruby also provides modules and mix-ins for adding functionality to
existing classes, this can often be a good way to implement utility
methods.

I guess you mean the files in helpers? Yes, this one I use already for
various utility functions, but helpers usually are targeted for views (I
can make them available in controllers, but they still would be
available in views too).

I see that there are several ways to do it. Could you also explain, why
my naive approach (to create a separate “lib” subdirectory below “app”
and put everything there) would be a bad idea? I have never seen someone
suggesting this, so I suspect it must have a drawback which I just don’t
see yet.

Ronald