On Wed, Feb 10, 2010 at 11:39, Paul Harrington <[email protected]> wrote: > Mat Brown wrote: >> Your data model layer should not be aware of application state (or even >> assume it is part of a web app). So, this should be done from the >> controller/view layer. > > More regards to this: I am *deathly afraid* of communicating with web > services during my apps' request/response cycles; you have no idea how > long it will take for the service to respond back to you, and when > something with the service goes wrong (after possibly minutes of > waiting), it tends to go wrong in completely unexpected and magical ways > (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 Groups > "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. -- You received this message because you are subscribed to the Google Groups "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.
