Wenn Sie ein Objekt in Ruby on Rails erstellen, welche Methode bevorzugen Sie und warum?

Question

Beim Schreiben der "create" -Methode für ein Objekt in einer Ruby on Rails-App habe ich zwei Methoden verwendet. Ich würde gerne eine Methode für einen saubereren und konsistenteren Code verwenden. Ich werde die beiden folgenden Methoden auflisten. Weiß jemand, ob einer besser ist als der andere? Wenn ja warum?

Methode 1:

def create1 
    # is this unsecure? should we grab user_id from the session 
    params[:venue]['user_id'] = params[:user_id] 

    begin 
    venue = Venue.create(params[:venue]) 
    @user_venues = @user.venues 
    render :partial => 'venue_select_box', :success => true, :status => :ok 
    rescue ActiveRecord::RecordInvalid 
    render :text => 'Put errors in here', :success => false, :status => :unprocessable_entity 
    end 
end 

Methode 2:

def create2 
    # is this unsecure? should we grab user_id from the session 
    params[:venue]['user_id'] = params[:user_id] 

    venue = Venue.new(params[:venue]) 
    if venue.save 
    @user_venues = @user.venues 
    render :partial => 'venue_select_box', :success => true, :status => :ok 
    else 
    render :text => 'Put errors in here', :success => false, :status => :unprocessable_entity 
    end 
end 

Answer 1

class VenuesController < ApplicationController 
    def create 
    @venue = @user.venues.create!(params[:venue]) 
    render :partial => 'venue_select_box', :success => true, :status => :ok 
    end 

    rescue_from ActiveRecord::RecordInvalid do 
    render :text => 'Put errors in here', :success => false, :status => :unprocessable_entity 
    end 
end 

Mit @user.venues auf diese Weise sicherzustellen, dass die Benutzer-ID wird immer entsprechend eingestellt werden. Außerdem schützt ActiveRecord das Feld :user_id vor der Zuweisung im Verlauf des Aufrufs #create!. Daher können Angriffe von außen nicht :user_id ändern.

In Ihren Tests können Sie überprüfen, ob das Ausführen eines POST für: create eine ActiveRecord :: RecordInvalid-Ausnahme auslöst.

Answer 2

ich von der Schule des Denkens bin, dass Ausnahmen sollten nicht für Routinebedingungen verwendet werden, so würde ich die zweite sagen ist besser.

Answer 3

Es kommt darauf an. Wenn Sie erwarten, dass alle create-Anweisungen funktionieren, verwenden Sie erstere, da der Fehler beim Erstellen und Speichern außergewöhnlich ist und möglicherweise eine Bedingung ist, von der das Programm nicht ohne weiteres wiederhergestellt werden kann. Wenn Sie die relationale Integrität (Fremdschlüssel-Migrationen durch RedHill Consulting) verwenden, werden außerdem Ausnahmebedingungen für Fremdschlüsselverletzungen ausgelöst, sodass Sie sie wahrscheinlich beim Erstellen oder Aktualisieren abfangen möchten.

Die zweite ist praktikabel und gut, wenn die Abfrage nicht erfolgreich ist, was Sie als Teil der täglichen Operation dieser bestimmten Aktion erwarten.

Auch Ihr Code Kommentar über Sitzung ist unsicher - die Sitzung ist der Ort, um die user_id zu setzen. Solange Sie überprüfen, ob der Benutzer authentifiziert wurde, bevor Sie etwas anderes tun, werden Sie in Ordnung sein.

Answer 4

Ich stimme Don Kommentar völlig zu. Aber ich würde mit dem Teil user_id noch einen Schritt weiter gehen und ihn als Vorfilter für das Modell festlegen.