2

ますます、MVC に関するモデルとヘルパーにすべてのコードを入れています。

ただし、コードを整理する場所がわからない場合があります。モデルに入れるか、ヘルパーに入れるか。それぞれの利点は何ですか。1つ速いですか、それとも同じですか。すべてのモデルがキャッシュされるという話を聞いたことがあるので、ほとんどのコードを配置するのに適しているようです。

たとえば、モデルまたはヘルパーで機能するシナリオは次のとおりです。

 def status
  if self.purchased
   "Purchased"
  elsif self.confirmed
   "Confirmed"
  elsif self.reserved
   "Reserved"
  else
   "Pending"
  end

終わり

購入済み、確認済み、予約済みのブール値フィールドがあるため、このステータスをデータベースに保存する必要はありません。では、なぜこれをモデルに入れたり、ヘルパーに入れたりするのでしょうか?

そのため、コードをモデルまたはヘルパーに配置することで得られるベスト プラクティスや利点については、両方に含めることができるかどうかはわかりません。

4

3 に答える 3

5

モデルのインスタンスが購入され、確認された場合、適切なステータスは「確認済み」ではなく「購入済み」であるという意味で、具体的な例にはビジネスルールが含まれています

したがって、あなたの例では、アプリケーションのビジネスルールの1つをコーディングしているため、メソッドをモデルに確実に入れます。

別の例:

def status_string
  case status
    when 0: "Purchased"
    when 1: "Confirmed"
    else
      "Pending"
   end
end

この場合、status_string メソッドはビュー ヘルパーまたはモデルで適切に定義できます。ビジネス ルールとは関係なく、値の表現を変更します。ビュー ヘルパーには html 関連の sw のみを配置する傾向があるため、モデルに配置します。ただし、国際化スキームによっては、同様のメソッドを View Helper に配置する方が適切な場合があります。

ビュー ヘルパーの良い例は、日時の値をアプリの標準表現に変換するアプリケーション全体のメソッドです。例えば

# application_helper.rb
def date_long_s(d)
  d.strftime("%A, %b *%d, %Y *%I:%M %p")
end
于 2010-05-03T03:52:48.560 に答える
3

これは本当に主観的なものであり、同意します。何かがモデルまたはヘルパーに属しているかどうかが明確でない場合があります。

例えば：

# using model
status ? status.nice_name : "Pending" 
# using helper 
nice_name(status)

ここでのヘルパーの明らかな利点は、ビューをきれいに保ちながら nil オブジェクトを適切に処理できることです。欠点は、コードがモデルから離れた別の場所にあることです

パフォーマンスに関しては、ヘルパーとモデルの使用に大きな違いは見られません。ステータス オブジェクトをプルするための DB ラウンド トリップがボトルネックになる可能性が高くなります。

于 2010-05-03T03:52:37.680 に答える
0

この種の状況では、定数ハッシュを使用します。

ハッシュはモデルファイルで次のように定義されています

STATUS = {
 1 => "Pending",
 2 => "Confirmed" 
}

このようにステータスごとに定数も宣言しています。

ST_PENDING = 1

これを宣言すると、クエリを作成するときに役立ちます。例えば、

MyModel.all(:status=>ST_PENDING)

データベーステーブルのステータスフィールドは数字なので、印刷するときはこれを使うだけです。

MyModel::STATUS[obj.status]
于 2011-01-10T00:08:51.173 に答える