Rails 5中使用装饰器模式优化模型功能的最佳实践

Great question—this is a common pain point when sticking to the fat-model thin-controller pattern without letting models turn into unmaintainable balls of mud. Let's break down your options, starting with Draper since that's what you're exploring, then move to more robust alternatives that might be a better fit for your use case.

First: Is Draper the right tool for this job? #

Draper was built primarily for view-layer decoration—think formatting dates for views, adding view-specific helper methods, or wrapping model data for presentation. While you can shoehorn it into handling business logic like logging and async validation, it's not its intended purpose. The "identical interface, different side effects" problem you're worried about is a direct result of this mismatch: Draper decorators are designed to feel like the original model, which makes it hard to tell them apart when side effects are involved.

If you still want to use Draper for business logic: #

1. Add explicit type checking to avoid misusage #

Don't let decorators and raw models be indistinguishable. Add a simple marker method to your decorator, and enforce its use in your business code:

class SubscriptionDecorator < Draper::Decorator
  delegate_all

  def decorated?
    true
  end

  def subscribe(user)
    # Delegate core subscription logic to the raw model
    object.subscribe_core(user)
    # Add your cross-cutting concerns here
    Rails.logger.info("User #{user.id} subscribed to list #{object.id}")
    SubscriptionValidationJob.perform_later(object, user)
  end
end

Then, in controllers or service entry points, add a guard clause to catch accidental raw model usage:

def subscribe_action
  subscription = Subscription.find(params[:id])
  decorated_sub = SubscriptionDecorator.decorate(subscription)
  raise "Must use decorated subscription for business operations" unless decorated_sub.decorated?
  
  decorated_sub.subscribe(current_user)
  # ...
end

This will catch mistakes early in development.

2. Avoid global decoration at all costs #

Draper's decorates_finders and decorates_association seem convenient, but they'll cause chaos by altering every query result in your app—including in callbacks, third-party gems, and places you don't expect. Only decorate models explicitly where you need them, ideally by centralizing decoration in service classes:

class SubscriptionService
  def self.subscribe(subscription, user)
    decorated_sub = ensure_decorated(subscription)
    decorated_sub.subscribe(user)
  end

  private

  def self.ensure_decorated(subscription)
    subscription.is_a?(SubscriptionDecorator) ? subscription : SubscriptionDecorator.decorate(subscription)
  end
end

By funneling all business operations through this service, you eliminate the risk of accidentally using a raw model.

3. Separate tests for models and decorators #

Test raw models only for their core responsibilities (e.g., "does subscribing a user add them to the database?"). Test decorators separately for their cross-cutting logic (e.g., "does subscribing trigger a log entry?" or "is the validation job enqueued?"). This keeps your tests focused and makes bugs easier to track:

# Model test: core logic only
RSpec.describe Subscription, type: :model do
  it "adds a user to the subscription list" do
    subscription = create(:subscription)
    user = create(:user)
    
    subscription.subscribe_core(user)
    expect(subscription.users).to include(user)
  end
end

# Decorator test: cross-cutting concerns
RSpec.describe SubscriptionDecorator, type: :decorator do
  it "logs the subscription event" do
    subscription = create(:subscription)
    user = create(:user)
    decorated_sub = SubscriptionDecorator.decorate(subscription)
    
    expect(Rails.logger).to receive(:info).with(/User #{user.id} subscribed/)
    decorated_sub.subscribe(user)
  end

  it "enqueues the validation job" do
    subscription = create(:subscription)
    user = create(:user)
    decorated_sub = SubscriptionDecorator.decorate(subscription)
    
    expect(SubscriptionValidationJob).to receive(:perform_later).with(subscription, user)
    decorated_sub.subscribe(user)
  end
end

A more robust alternative: Service Objects #

For business logic like subscriptions (with logging, async jobs, and validation), Service Objects are the de facto Rails community standard. They're designed to encapsulate complex workflows, keep models focused on data and core rules, and eliminate the ambiguity of decorators.

How to implement this: #

1. Strip your model down to core logic:

# app/models/subscription.rb
class Subscription < ApplicationRecord
  has_many :user_subscriptions
  has_many :users, through: :user_subscriptions

  # Only handle database-level subscription logic here
  def subscribe_core(user)
    users << user unless users.include?(user)
  end
end

2. Create a service class for the full workflow:

# app/services/subscription_subscribe_service.rb
class SubscriptionSubscribeService
  def initialize(subscription, user)
    @subscription = subscription
    @user = user
  end

  def call
    # Execute core model logic
    @subscription.subscribe_core(@user)
    
    # Handle cross-cutting concerns
    log_subscription
    enqueue_validation_job
    
    # Return success/failure status
    @subscription.persisted?
  end

  private

  def log_subscription
    Rails.logger.info("User #{@user.id} subscribed to list #{@subscription.id} at #{Time.current}")
  end

  def enqueue_validation_job
    SubscriptionValidationJob.perform_later(@subscription, @user)
  end
end

3. Call the service from your controller:

def create
  subscription = Subscription.find(params[:id])
  service = SubscriptionSubscribeService.new(subscription, current_user)
  
  if service.call
    redirect_to subscription_path(subscription), notice: "Successfully subscribed!"
  else
    redirect_to subscription_path(subscription), alert: "Subscription failed."
  end
end

Why this is better than Draper for business logic: #

• Clear boundaries: Models handle data and core rules; services handle workflows and cross-cutting logic.
• No ambiguity: There's no question of "should I use the raw model or the decorator?"—all business operations go through the service.
• Easier testing: Services are isolated, so you can mock dependencies like logs or jobs without touching the model.
• Better scalability: Adding more logic (like sending welcome emails or updating analytics) is as simple as adding a method to the service, not cluttering your model or decorator.

Final Recommendation #

Since your goal is clean code organization and easier testing, I strongly recommend going with the Service Object pattern over using Draper for business logic. Draper shines in the view layer, but service objects are purpose-built for exactly the kind of workflow you're dealing with.

If you do stick with Draper, follow the guard clauses and explicit decoration rules to avoid the misusage pitfalls you're worried about.

内容的提问来源于stack exchange，提问作者Schwern