23

We are building out apps that have Models that are not database components. We are curious to learn what others are doing in the rails community to address this subject.

We are struggling with where to put them.

Should we have:

app/models/domain

or

app/domain/models

or perhaps

app/models   # Business Models
app/models/ar # Active Record Models

or perhaps

app/models/domain/   # Business Models
app/models/domain/ar # Active Record Models

Part of this is that we are struggling with how close to be to rails standards and how much to create a structure that will be good for what we need.

If we think of the objects as Service Objects, we could have

app/models/service-object

and

app/models/ # For plain active record

Another route to go down is not have stuff within app, e.g.

/service_objects

instead of

/app/models/service_objects

Presumably if we want access via a rails app we're better of using app/ in order to take advantage of convention over configuration.

Michael Durrant
  • 93,410
  • 97
  • 333
  • 497
  • 5
    The directory is called "models". It's not called "active_record descendants only". I just put them together and throw Mongoid models on top :) – Sergio Tulentsev May 09 '13 at 15:59
  • You could place them under `lib` if you really want to stick with AR-only in models – Raindal May 09 '13 at 16:01
  • 1
    I'd reconsider sticking them in `lib` but its still an option. I like to stick files in lib that I'd consider good candidates for extracting into gems for re-use. – Leo Correa May 09 '13 at 16:05

4 Answers4

19

In my experience, the division of where you put these models comes down to what they functionally represent in the specific context of your application.

I usually reserve app/models for resource based models. If that model represents a resource that is instantiated and manipulated by your application it goes here. Doesn't need to be AR or db backed.

If the model serves a consistent functionality but varies on the parameters, I give them a top level dir in app. Such as app/mailers app/observers etc. However, if you have one resource that requires an observer, it might not make sense to have an app/observers dir with just one file in it.

Everything else goes in lib. There are a few reasons why this is preferable.

  1. You can choose when to require the files in lib. You can be much more selective about which files get loaded when your app starts. If you put everything in app/models you've got no granularity over what gets loaded.

  2. Namespacing your models as your app grows is easier in lib. Sure you can namespace in app/models but several layers of nesting in app/models always ends up nasty. It's best to keep the namespacing in lib.

  3. Housekeeping is made much easier when you've got things in their functionally correct place. It's not a resource? It's not an observer? Must be in lib. The whole reason you're putting thought into this up front is to provide discoverability to developers down the line.

Matthew
  • 5,435
  • 6
  • 25
  • 29
14

For service objects you'll usually have them directly under the app directory app/services/. Workers and serializers also follow this pattern app/workers/ app/serializers/. As for your models that are not AR you can still stick them in the models directory. That's just my take on it.

Leo Correa
  • 19,131
  • 2
  • 53
  • 71
  • +1 That is useful, thanks. We're a little bit concerned that as the application grows we might end up with 34 Active Record models and 12 Non-Active Record ones and that then models would have a mish-mash of 46 together. That might be ok, we're just wondering about that potential future also. – Michael Durrant May 09 '13 at 16:21
  • 2
    Agree with this - at a certain point, if you have stable non-AR models that fit into specific functions, you can always extract them into Modules. – mikeryz May 09 '13 at 16:36
  • Well it also comes down to separating concerns by applications. You don't want a single application to get so big that you can't manage it. For example, when an app gets too big, I'd consider separating auth into its own application and follow that pattern then just communicate through APIs. – Leo Correa May 09 '13 at 17:50
11

If they are models, you should put them into app/models since this directory is meant for models and not just ActiveRecord subclasses.

severin
  • 10,148
  • 1
  • 39
  • 40
2

If you have classes that are not models, for instance they perhaps represent a form, I'd say go ahead and put them in lib.

If they are orthogonal to your application, ie: it's some interface used to call another application, you might wrap it up as a private or public gem depending on its applicability to the rest of the community.

In the end, it doesn't really matter. Pick one thing, and agree on it with the rest of your team. Moving things around should be pretty easy, especially if you add whatever you decide on using to the load path for your application ($LOAD_PATH += '...').

Adam Sanderson
  • 470
  • 5
  • 7