RE: Business Logic and where to place with rails

Rails
1

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

2

On 5/5/06, Chris B. [email protected] 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

3

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. [email protected] 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

4

“Chris” == Chris B. [email protected] 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. <[email protected]>
	 http://www.livejournal.com/users/cdybedahl/
"Ah, optimism. I remember optimism." -- Anya, Buffy the Vampire

Slayer

5

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.

6

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.