# RE: Business Logic and where to place with rails **URL:** \ **Category:** Rails\ **Created:** [May 5, 2006, 1:31am UTC](https://www.ruby-forum.com/t/re-business-logic-and-where-to-place-with-rails/94494 "2006-05-05T01:31:54Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\ **Post date:** [May 5, 2006, 1:31am UTC](https://www.ruby-forum.com/t/re-business-logic-and-where-to-place-with-rails/94494/1 "2006-05-05T01:31:54Z")
According to the model-view-controller architecture, your business logic should go into the controller. Don’t put your business logic in a model like someone suggested, that is wrong. If you have common business logic that you would like to be shared across multiple controllers, then you might consider sticking it in lib, but remember that business logic is the glue that sticks your models (data) to views (user input/output). So it is less likely that you will be able to abstract much, but that all depends on your processes. Chris ---
**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\ **Post date:** [May 5, 2006, 3:15am UTC](https://www.ruby-forum.com/t/re-business-logic-and-where-to-place-with-rails/94494/2 "2006-05-05T03:15:13Z")
On 5/5/06, Chris B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > According to the model-view-controller architecture, your business logic > should go into the controller. > > Don’t put your business logic in a model like someone suggested, that is > wrong. No, that’s the entire point of having a model. Sticking business logic _anywhere_ else is completely and totally wrong. Controllers are for the interaction model, Models represent your business domain. – Cheers Koz ---
**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\ **Post date:** [May 5, 2006, 5:41am UTC](https://www.ruby-forum.com/t/re-business-logic-and-where-to-place-with-rails/94494/3 "2006-05-05T05:41:52Z")
Yeah, I am sorta going down with this in the thread: Should controllers be “smart”? I am wrong about this (somewhere way back I decided that MVC was just another term for the old 3 tiered architecture, which it isn’t). But I am seeing a lot of grey area and maybe business logic isn’t the correct terminology. I know for a fact that business RULES (like can’t withdraw more money than in your acct, etc) completely belong in the model. But I am getting a little confused about the differences between application logic and business logic and how they belong in a “rails” model. I posted a question in that other thread, maybe you know answer… Should your model (as in the M in MVC) really be isolated enough that it could potentially be used in a complete non-web based application if needed? Check out the thread titled “Should controllers be “smart”?” Thanks, Chris Michael K. wrote: > On 5/5/06, Chris B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > According to the model-view-controller architecture, your business logic > > should go into the controller. > > > > Don’t put your business logic in a model like someone suggested, that is > > wrong. > > No, that’s the entire point of having a model. Sticking business > logic _anywhere_ else is completely and totally wrong. > > Controllers are for the interaction model, Models represent your > business domain. > > – > Cheers > > Koz ---
**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\ **Post date:** [May 5, 2006, 7:53am UTC](https://www.ruby-forum.com/t/re-business-logic-and-where-to-place-with-rails/94494/4 "2006-05-05T07:53:15Z")
> > > > > “Chris” == Chris B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) writes: > Should your model (as in the M in MVC) really be isolated enough > that it could potentially be used in a complete non-web based > application if needed? ## Yes. If nothing else so because that’s not really all that unlikely to happen. The basic frameworks for both SOAP (which while using HTTP isn’t really Web) and email are already there in your Rails app. Some day you’ll want to use it (to do email posts to your blog app, or something). That’ll be easier the clearer the dividing line between the M and the VC is. ``` Calle D. http://www.livejournal.com/users/cdybedahl/ "Ah, optimism. I remember optimism." -- Anya, Buffy the Vampire ``` Slayer ---
**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\ **Post date:** [May 8, 2006, 3:45pm UTC](https://www.ruby-forum.com/t/re-business-logic-and-where-to-place-with-rails/94494/5 "2006-05-08T15:45:07Z")
Michael K. wrote: > No, that’s the entire point of having a model. Sticking business > logic _anywhere_ else is completely and totally wrong. > > Controllers are for the interaction model, Models represent your > business domain. Yes, this is correct. You can see this in the Agile Development with rails book. Fernando L. ---
**Author:** ![dacbo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b9e5f3/32.png) [@dacbo](https://www.ruby-forum.com/u/dacbo)\ **Post date:** [May 5, 2006, 1:59pm UTC](https://www.ruby-forum.com/t/re-business-logic-and-where-to-place-with-rails/94494/6 "2006-05-05T13:59:06Z")
I like to think of it this way… Business logic never changes regardless of the framework used to implement your system. The example you gave about withdrawing money makes this clear. That rule would stand even if you ran your business on people, paper, and filing cabinets rather than an MVC. Now, your application logic could change depending on the framework/tools you choose to run your business. If your system ran on people, paper, and filing cabinets then you application logic would be drastically different compared to a system running on an MVC.