3 ms·

It seems that people forget what "model" (in MVC) really means. A model (in general) is a simplification of the world. The world is so complex that you can't po

by judofyr 15y ago

It seems that people forget what "model" (in MVC) really means. A model (in general) is a simplification of the world. The world is so complex that you can't possibly reason about it at once, so you split it up into smaller models that are easier to understand. It's exactly the same in MVC: the model is the definition of your application's world; a simplification that your computer can work with. Yes, Rails ship with ActiveRecord, which makes it dead simple to define data models that you need to store, but the app/models/ is far from limited to only data storage. app/models is about the business logic of your application. It seems to me that all of the files the article wanted to place under lib/ actually belongs under app/models. Yes, I agree that it's nice to be able to test your application outside of Rails, but whether you place the files under app/models or lib/ doesn't change that. Yes, it might be useful to abstract it out to a gem, and then you can move it into a lib/-directory (since there is no MVC of a Ruby library), but as long as you're inside the realm of a Rails application you should put everything that's related to the business logic in app/models. So, in summary: If it's related to the BUSINESS LOGIC of your app: Put it in app/models. If it's just GENERAL stuff: Put it in lib/ (or better: create a gem out of it).

Void_ 15y ago
Say you're writing an app that has simple business logic. Easy, you put that logic into model. Then you realize you need to write much more business logic code. No problem, model. But your model classes are getting fat and it looks ugly. So you refactor the code into modules. Now somebody is browsing your code and they are ripping their hair off, because there's a method on Order object and there are 6 modules included in the Order object. Before you realize it, you're violating not only MVC but also OOP. If you used Services, you could model nice controller/manager classes in OOP manner, with responsibilities nicely distributed. These are your controllers. Rails controllers are just the HTTP interface.
- judofyr 15y ago
  I'm not suggesting that you should create modules and include these into your ActiveRecord-models. Feel free to create any kind of class/module/object/whatever, but as long it's related to the business logic put it under app/models.
  - saturnflyer 15y ago
    +1 app/models is for domain models
generalk 15y ago
That's fine, let's not get pedantic here. If you want to put your non-database-backed stuff lib/ and the ActiveRecord bits in app/models, fine. If you want to shove them all in app/models, that's good too. There's really no argument for or against; either way the code should be documented with tests and a README.

by judofyr 15y ago

Void_ 15y ago

Say you're writing an app that has simple business logic. Easy, you put that logic into model. Then you realize you need to write much more business logic code. No problem, model. But your model classes are getting fat and it looks ugly. So you refactor the code into modules. Now somebody is browsing your code and they are ripping their hair off, because there's a method on Order object and there are 6 modules included in the Order object. Before you realize it, you're violating not only MVC but also OOP. If you used Services, you could model nice controller/manager classes in OOP manner, with responsibilities nicely distributed. These are your controllers. Rails controllers are just the HTTP interface.

judofyr 15y ago
I'm not suggesting that you should create modules and include these into your ActiveRecord-models. Feel free to create any kind of class/module/object/whatever, but as long it's related to the business logic put it under app/models.
- saturnflyer 15y ago
  +1 app/models is for domain models

generalk 15y ago

That's fine, let's not get pedantic here. If you want to put your non-database-backed stuff lib/ and the ActiveRecord bits in app/models, fine. If you want to shove them all in app/models, that's good too. There's really no argument for or against; either way the code should be documented with tests and a README.