Ruby on Rails中的User.new解释？ （摘自Michael Hartl的教程）

Question

I have searched everywhere to try to find an explanation of how this works/what its purpose is, but I cant find anything helpful. I am doing Michael Hartl's tutorial, and my question is mainly about the two actions: 'new' and 'create'. The new action has the following:

def new
  @user = User.new
end

In the view corresponding to the 'new' action, there is a form_for helper, where users can type in their attributes and hit submit. As expected, the beginning of the form_for helper looks like this: form_for(@user)

However here is where I am stumped... In the create action, there is the following code:

def create
  @user = User.new(user_params)  
  #user_params is a function we defined which simply returns the permitted params from the user.

What is the purpose of @user = User.new in the 'new' action? What does User.new even accomplish? I am assuming that the instance variable @user is necessary to pass to the form, but in that case, why do we have to redeclare an @user isntance variable in 'create'? Isn't it sufficient to have only @user = User.new(user_params) in our 'create' action? Is the User.new somehow necessary to make the form function properly?

I am mainly just trying to figure out what @user = User.new accomplishes in our 'new' action and its corresponding 'new' view (with the form), and why it is necessary when we have a 'create' action which actually CREATES the object. ANY help is SO GREATLY APPRECIATED. Thank you all for always doing your best to explain. Thank you ahead of time to anyone who answers this.

Answer 1

The new and create are different actions. New is called when you get the new route. Create is called when you post to the new route. So, you have to create the user in new so they're available in the form. You have to create the user with the form contents in create so you can save it to the database.

You can't assume that the request to new will go to the same rails instance as the request to create. It's common to run multiple instances of your app behind a proxy.

Answer 2

It's called object orientated programming

---

HTTP

In Ruby, each variable you define is an object . These objects are then manipulated throughout each instance of the app.

In traditional ( stateful ) applications, your computer is able to store a number of objects in memory, and since your application is always in state , you'll be able to manipulate them from a single invocation.

In HTTP ( stateless ) applications, you have to rebuild the objects with each call. Because your application doesn't retain state (memory) between each request, you have to build the objects again.

This is why Rails "variables" are called with a class function on the model (class): User.find ...

--

Thus, when using the following:

#app/controllers/your_controller.rb
class YourController < ApplicationController
   def new
      @user = User.new #-> invokes a new user object
   end

   def create
      @user = User.new user_params #-> invokes a new user object & populates with your params
      @user.save #-> "saves" the new record
   end

   def show
      @user = User.find params[:id] #-> stateless means you have to rebuild the object again
   end
end

... what you're doing is rebuilding the object each time your actions are invoked.

This is one of the pitfalls of using HTTP - your server is "dumb" and cannot retain state between requests. Although Rails does a great job at making it a seamless process, it can be difficult if you haven't got your head around it yet.

Answer 3

Most generally, users enter data and we programmer-types traditionally store it in a relational database.

This creates an "impedance" between a relational model (ie, tables and rows) and an object-oriented one (roughly, classes and instances).

ORMs like ActiveRecord help abstract much of this tedium, and in this way model instances--such as those we're creating in controller actions--serve as helpful containers for data.

This lets us easily represent models in views when gathering user input, and bind inputs to model attributes when persisting it (basic CRUD).

The separate controller actions merely represent these two steps in the process, as any Web-based app ultimately speaks HTTP.

This is really the whole benefit and genesis of Rails and similar MVC frameworks, born in a time of relational databases and server-side rendering. (Though they are increasingly coping with and adapting to an environment that now includes document/object-oriented databases and client-scripted front-ends.)