On Wed, Feb 10, 2010 at 11:39, Paul H. [email protected]
(often you’ll not even get a timeout!). Doing this kind if ish in a
background service is trivial if this logic already exists in a model;
its impossible if the logic is in a controller.
Posted via http://www.ruby-forum.com/.
You received this message because you are subscribed to the Google G. “Ruby on Rails: Talk” group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
When we use the word “model”, we can mean different things - a narrow
definition would be an object representing persistent data, e.g. an
ActiveRecord instance. We also use it more broadly to mean “a class
encapsulating business logic”.
I’m all for skinny controllers, but I think for non-trivial apps it’s
important to make a distinction between the data model (which should
really just be in the business of representing data) and other things
that encapsulate business logic - e.g., the Command pattern. That
pattern is likely appropriate for the Facebook task here - and of
course, if you encapsulate business tasks in a Command object, they
can be trivially called either synchronously in the controller or
asynchronously in a background job. And, for what it’s worth,
background jobs are a great example of why the data model shouldn’t
assume it’s running inside a web app. The use of the asset_host
configuration is a common pattern and it works, but in the end it’s
really just a fancy way of setting a global variable.
In summary: agreed entirely that the logic should be in the model, if
by “model” we mean “a class that isn’t the controller”. And also
agreed entirely that a background job is the right place to do this.
But I maintain that the data model shouldn’t access, or assume the
existence of, web application state.