What is a good practice for storing additional classes

rubyonrails-talk
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 Fischer 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 Walker 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