Should I prevent record editing using a filter in my controller or a callback in my model?

To preserve data integrity, I need to prevent some models from being modified after certain events. For example, a product shouldn't be allowed to be written off after it has been sold.

I've always implemented this in the controller, like so (pseudo-ish code):

def ProductsController < ApplicationController
  before_filter require_product_not_sold, :only => [ :write_off ]

private
  def require_product_not_sold
    if @product.sold?
      redirect_to @product, :error => "You can't write off a product that has been sold"
    end
  end
end

It just struck me that I could also do this in the model. Something like this:

def Product < ActiveRecord::Base
  before_update :require_product_not_sold

private
  def require_product_not_sold
    if self.written_off_changed?
      # Add an error, fail validation etc. Prevent the model from saving
    end
  end
end

Also consider that there may be several different events that requir开发者_运维百科e that a product has not been sold to take place.

I like the controller approach - you can set meaningful flash messages rather than adding validation errors. But it feels like this code should be in the model (eg if I wanted to use the model outside of my Rails app).

1. Am I doing it wrong?
2. What are the advantages of handling this in my model?
3. What are the disadvantages of handling this in my model?
4. If I handle it in the model, should I really be using validates rather than a callback? What's the cleanest way to handle it?

Thanks for your ideas :)

It seems like you already have this one covered, based on your question. Ideally a model should know how to guard its state, as data objects are typically designed with portability in mind (even when they'll never be used that way).

But in this case you want to prevent an action before the user even has access to the model. Using a model validation in this case means you're too late and the user has already gone farther than he should by having access to and attempting to write off a product which should never have been accessible based on its sold status.

So I guess the ideal answer is "both." The model "should" know how to protect itself, as a backup and in case it's ever used externally.

However in the real world we have different priorities and constraints, so I'd suggest implementing the change you listed if feasible, or saving it for the next project if not.

As far as using a model callback versus a validation, I think that's a trickier question but I'll go with a validation because you'd likely want to present a message to the user and validation is built for exactly that use (I'd consider this more of a friendly and expected user error than a hostile or security-related one which you might handle differently).

Is that along the lines of what you've been considering?