質問

ActiveRecordを使用してユーザーに関する情報を管理しています。 Userクラスには、予想されるload()、insert()、update()、delete()の各メソッド、setter、getter、その他いくつかがあります。しかし、他の特定のメソッドをUserクラスに含めるか、共同作業者が処理するかを決定するのに問題があります。

例を次に示します。

ユーザーが要求する可能性のある確認が必要なトランザクションがいくつかあります。これは従来の方法で処理されます。リンク付きのメールをユーザーに送信します。リンクをクリックすると、ユーザーがトランザクションの続行を実際に望んでいることが確認されます。検証キーとその有効期限のハッシュは、ユーザーレコードの一部として保持されます。

このプロセスのどこに線を引きますか?検証を処理する共同作業者が必要ですか(たとえば、クエリ文字列からプレーンテキストの検証キーを取得し、ユーザーオブジェクトをパラメーターとして受け入れることによって)。または、これをUserクラスによって内部的に処理する必要があります(メソッド呼び出しでプレーンテキストの検証キーを渡す)?

もちろん、検証時に発生する非常に次のことは、トランザクションがアクティブレコードへの更新を必要とすることであり、そこでは、Userクラスが責任を負わなければならないようです。

提案はありますか

役に立ちましたか?

解決

このタスクを confirmations テーブルを管理する共同作業者に委任する必要があります。

すべての確認要件を追跡するには、 Confirmation モデルを使用します。モデルは User に属し、確認ハッシュと確認するアクション( activate_account change_password または change_email など)。

Confirmation コントローラーは、確認ハッシュを検証し、適切なモデルで適切なアクションをチェーンします(例: activate_account -&gt; user.activate( ) change_password -&gt; user.setPassword()など)、 confirmations <から Confirmation を削除します/ code>テーブルは正常に完了します。

これにより、ロジックのより良い分離が可能になるだけでなく、より良いスケーリングが可能になります。特定のユーザーの保留中の複数の確認を楽しませる(パスワードの変更を確認する 別の変更を確認するなど)

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top