Forum: Ruby on Rails RE: Business Logic and where to place with rails

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Chris B. (Guest)
on 2006-05-05 03:31
(Received via mailing list)
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
Michael K. (Guest)
on 2006-05-05 05:15
(Received via mailing list)
On 5/5/06, Chris B. <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
Chris B. (Guest)
on 2006-05-05 07:41
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> 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
Calle D. (Guest)
on 2006-05-05 09:53
(Received via mailing list)
>>>>> "Chris" == Chris B. <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. <removed_email_address@domain.invalid>
		 http://www.livejournal.com/users/cdybedahl/
    "Ah, optimism. I remember optimism." -- Anya, Buffy the Vampire
Slayer
Vince P. (Guest)
on 2006-05-05 15:59
(Received via mailing list)
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.
Fernando L. (Guest)
on 2006-05-08 17:45
(Received via mailing list)
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.
This topic is locked and can not be replied to.