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.
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.
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.
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
.
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.
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.
If they are models, you should put them into app/models
since this directory is meant for models and not just ActiveRecord subclasses.
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 += '...'
).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With