2

以下のように、データ アクセスにリポジトリ パターンを使用しているとします。

#userController.coffee

# `userId` is obtained from the session

user =
  email: 'Bob'
  password: 'Secret'

db.userRepo(@userId).create user, (err, data) =>
  # return results in http response or socket.io

これは、このメソッドの呼び出し中に問題が発生する可能性があることです。

  • データベースへのアクセス エラー
  • クエリの構文エラー
  • ミュータティブクエリ中に制約を破る（私はnode-mysqlを使用しています）
  • Auserには、フィールドの欠落などの検証エラーがあります。
  • ユーザーは既に に存在しuser.emailます。

私の質問は、コールバックでこれらの各エラーを返す方法ですか?

コールバック引数のオプション:

  • (err, data)-errは、発生したすべてのエラーの配列です。
  • (err, data)-err検証エラーはどこにあり、データベース エラーは例外としてスローされます。
  • (err, data)- が既に存在する場合を除き、上記と同じuserです。これはエラーではなく、予期される動作であるため、null を返します。
  • (err, data, validation)-validationは検証エラーの配列またはnull.
  • (err, data, model)- 検証プロパティを持つモデル クラスを返す - アクティブ レコード スタイル。

気軽に違うものを提案してください。

フォローアップの質問: 引数の検証はどこで行うべきですか? コントローラー/ルーティング レベル、データ アクセス レベル、または SQL データベースでしょうか?

  • どちらのレベルでも、コードの重複が多くなります。私はDRYの方が好きです。
  • 静的型付けを使用すると、コントローラー レベルでバグを検出し、型システムを信頼できます。静的型付けがないと、データ層は誰も本当に信頼できないため、おそらくすべての検証ロジックが必要です。
  • 通常は静的型チェックで検出されるエラーは、修正する必要があるため、エラーをスローする必要があります。それらはバグです。ただし、それらが見つからない場合は、Internal Server Error 500 やスタック トレースではなく、ユーザーにわかりやすいメッセージを表示したいと考えています。
  • これをパブリック API に進化させたい場合は、すべての検証が必ず必要になります。

ノードバリデーターとリバリデーターの組み合わせを使用して、オブジェクトと引数を検証することを計画しています。

バックストーリー: 私は Scala/Play から Node/Express に移行しました。これは、より大きなコミュニティ、優れた Web ソケット サポート、および開発者の生産性のためです。Sequelize ORM を使い始めた後、これは制約が多すぎると判断し、結合の作成に問題があり、私のスキーマはとにかく単純だったので、生の SQL を書き始めました。開発速度が最初に向上した後、静的型付けを毎日戻したいと思うようになりました。私が書いているテストと検証コードの数はかなり多くなっています。

4

1 に答える 1

0

(err, data, validation)ユーザーが再入力する必要がある無効な入力と、errテストおよびプロトタイピング中にログ ファイルに詳細を書き込むときにかなりのエラー メッセージを出力する可能性がある実際の DB エラーを簡単に確認できるようにすることをお勧めします。

于 2012-08-27T02:48:28.403 に答える