+1 -- models are models. It doesn't matter if they're ActiveRecord based or not. They could be connected to web services. They could be connected to files. Or none of these. Models are models.

-- gw


On Jun 14, 2011, at 10:49 AM, Kevin Ball wrote:

Hi Glenn,

My take would be that if they are dealing with local data and business logic, app/models is absolutely the right place for them.

We get into this feeling in the rails world like all models have to be DB backed and inherit from active record, and in my opinion that harms our code organization. It both leads to things getting placed outside of their natural location (e.g. in lib) or getting shoe-horned into a larger active record class when they should really be standalone models that have nothing to do with active record.

-Kevin

On Tue, Jun 14, 2011 at 10:43 AM, Glenn Little <[email protected]> wrote:
I want to define a class or two that are kinda-sorta model like, but
not really.  They deal with local data and business logic, but are not
at all "active-record"-y.  Is there a best-practice place to define
this sort of thing?

I ended up putting it in appname/lib/myclass.rb, but that didn't feel
quite right for some reason.  I had considered putting it in
appname/app/models and am still thinking maybe that's the right place,
even though this isn't a model in the usual sense.

One other place I tried putting it was in appname/lib/xyz/myclass.rb
(the "xyz" made organizational sense, and this is where I really
wanted to put it) but I ran into all sorts of very strange issues that
looked like dependency issues when rails tried to load it.  It almost
seemed like it was getting loaded twice and bombing out the second
time, but I was never able to fully get a handle on what was going on.
 So I punted and just put it in lib for now but...

Is there a typical pattern for this sort of thing?  This is rails2 by
the way, if it makes any difference.


--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby

Reply via email to