[Rails] Program logic behind Ruby On Rails

[Stefan Arentz]

On Jan 14, 2005, at 4:06 AM, Michael Koziarski wrote:

>> I'd imagine that the controller and view parts are designed to be used
>> through a web browser, not through the command line.
>
> Taking it a step further,  the command line application is a
> completely different user interface,  and it *shouldn't* share the UI
> releated components (i.e. View and Controller).
>
> The scripts I've built use Active Record directly,  i.e:
>
> User.new_users.each do |user|
>   user.welcome #sends welcome email
> end
>
> This highlights the importance of having your business logic in your
> model,  not in your controllers.

I agree that it is bad having the logic in controllers. But I also 
don't like to put business logic in in the domain model. I try to keep 
the model objects as lightweight as they can be; if I add logic to them 
it is usuall for handling relationships between model objects or simple 
getter/setter logic.

My approach is this: I move all business logic, the glue that actually 
puts model objects together to make sense as a whole, in a Service 
Layer. Personally I think this is a much cleaner design because it 
doesn't pollute the domain model with application logic.

  http://www.martinfowler.com/eaaCatalog/serviceLayer.html

It also makes it easier to export the application logic to different 
modules/layers that don't have to know all the details about the domain 
model.

Lastly, I'm not sure how this is handled in Rails, in the Java world 
this setup allows me to do transaction demarcation in one place since i 
simply annotate the methods in the service layer with the proper 
transaction strategy.

For me, putting logic in the domain model is a big step backwards.

  S.