Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is not your application

blog.firsthand.ca

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Rails is not your application

#21

Post by judofyr »

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).

Re: Rails is not your application

#22

Post by Void_ »

judofyr wrote: post #21

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 wit…

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.

Re: Rails is not your application

#23

Post by judofyr »

Void_ wrote: post #22
judofyr wrote: post #21

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 wit…

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 includ…

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.

Re: Rails is not your application

#24

Post by MostAwesomeDude »

k33n wrote: post #3

Sounds like you shouldn't be using Rails if this is your philosophy. I'm of the school of thought that if you're going to use a framework when building an app, then you should lean on it for just about any task that it will let you. Especially if you're using a well-maintained and widely used framework like Rails. There are multiple benefits to this approach. For one thing, it makes it easier to onboard new team memb…

Rails is not your application framework. It is not well-suited to being your application framework. We have exactly this problem in the Python world, where people lean on Django for everything, and insist on making everything interoperate with Django's view of the way the world should be.

It doesn't work. Factor out as much as you can and make as much of your code into units as possible. You want to be able to test your code, run it and inspect it, and have it overall be very non-magical.

Re: Rails is not your application

#25

Post by mnutt »

afex wrote: post #15

i go one step further, and put the domain layer behind a network interface (http or other) with a versioned API. IMO, trapping behavior inside a single application is just as bad as tying it to a framework. the domain layer needs to be available to the entire organization. rails is just a tool to build a front-end app. i have many of those on my project. some rails, some sinatra. if they want to access shared behavio…

I would only reach for service-oriented architecture after the application is very mature and it is apparent which parts will benefit by moving to their own services.

Re: Rails is not your application

#26

Post by afex »

mnutt wrote: post #25
afex wrote: post #15

i go one step further, and put the domain layer behind a network interface (http or other) with a versioned API. IMO, trapping behavior inside a single application is just as bad as tying it to a framework. the domain layer needs to be available to the entire organization. rails is just a tool to build a front-end app. i have many of those on my project. some rails, some sinatra. if they want to access shared behavio…

I would only reach for service-oriented architecture after the application is very mature and it is apparent which parts will benefit by moving to their own services.

or the moment you have more than one application running. (which for many products is day #1)

Re: Rails is not your application

#27

Post by div »

mnutt wrote: post #25
afex wrote: post #15

i go one step further, and put the domain layer behind a network interface (http or other) with a versioned API. IMO, trapping behavior inside a single application is just as bad as tying it to a framework. the domain layer needs to be available to the entire organization. rails is just a tool to build a front-end app. i have many of those on my project. some rails, some sinatra. if they want to access shared behavio…

I would only reach for service-oriented architecture after the application is very mature and it is apparent which parts will benefit by moving to their own services.

I find rails in particular to be very easy to just "api all the things" right off the bat. Add in some nice authentication / authorization with something like devise and CanCan and you will be saved from the headache of bolting an api onto your app as an afterthought.

Re: Rails is not your application

#28

Post by saturnflyer »

judofyr wrote: post #23
Void_ wrote: post #22

Earlier quoted context omitted.

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 includ…

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.

+1 app/models is for domain models

Re: Rails is not your application

#29

Post by generalk »

judofyr wrote: post #21

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 wit…

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.

Post reply on HN