Rails - May 2006 - Business Logic and where to place with rails

I am having an issue of deciding where I should put the business code 
for example the more complex code coming off the controller.  Right now, 
I am just thinking to put it in the ''lib'' directory and the do
something
along these lines:

require_dependency "system_process"
class SystemMessageController < ApplicationController

  include SystemProcess
...
...

Where there is a file called ''system_process.rb'' in my
''lib'' directory.

Is this good, bad for rails design?

-- 
Berlin Brown
(ramaza3 on freenode)
http://www.newspiritcompany.com
http://www.newspiritcompany.com/newforums
also checkout alpha version of botverse: 
http://www.newspiritcompany.com:8086/universe_home

Berlin Brown wrote:
> I am having an issue of deciding where I should put the business code 
> for example the more complex code coming off the controller.  Right now, 
> I am just thinking to put it in the ''lib'' directory and
the do something
> along these lines:
> 
> require_dependency "system_process"
> class SystemMessageController < ApplicationController
> 
>  include SystemProcess
> ...
> ...
> 
> Where there is a file called ''system_process.rb'' in my
''lib'' directory.
> 
> Is this good, bad for rails design?
That really depends on what SystemProcess is doing.  9 times out of 10, 
it should be in a model, though...

-- 
Alex

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


-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Berlin Brown
Sent: Wednesday, May 03, 2006 4:28 PM
To: rails@lists.rubyonrails.org
Subject: [Rails] Business Logic and where to place with rails

I am having an issue of deciding where I should put the business code 
for example the more complex code coming off the controller.  Right now,

I am just thinking to put it in the ''lib'' directory and the do
something

along these lines:

require_dependency "system_process"
class SystemMessageController < ApplicationController

  include SystemProcess
...
...

Where there is a file called ''system_process.rb'' in my
''lib'' directory.

Is this good, bad for rails design?

-- 
Berlin Brown
(ramaza3 on freenode)
http://www.newspiritcompany.com
http://www.newspiritcompany.com/newforums
also checkout alpha version of botverse: 
http://www.newspiritcompany.com:8086/universe_home

_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 5/5/06, Chris Bruce <cbruce@sleeter.com> 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

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 Koziarski wrote:
> On 5/5/06, Chris Bruce <cbruce@sleeter.com> 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

-- 
Posted via http://www.ruby-forum.com/.

>>>>> "Chris" == Chris Bruce <cbruce@sleeter.com>
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 Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
    "Ah, optimism. I remember optimism." -- Anya, Buffy the Vampire
Slayer

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.




On 5/4/06 11:41 PM, "Chris Bruce" <cbruce@sleeter.com> wrote:
> 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 Koziarski wrote:
>> On 5/5/06, Chris Bruce <cbruce@sleeter.com> 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
>

Michael Koziarski 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 Lujan