2

私はWebアプリケーションを持っています：ExtJsフロントエンド-EntityFramework +SQLServerをバックエンドとして。エラーシナリオの1つを見てみましょう。

  • ユーザー名にデータベースの制約があります（名前は一意である必要があります）
  • そのためのクライアント側の検証はありません（そのような検証を一般的にする方法はありますか？）
  • 同じ名前のユーザーを挿入しようとすると、サーバーは500エラーを返します。
  • IISがオンになっている同じマシンから実行すると、完全なエラーメッセージ（基本的にはキー違反などのSQL例外の説明）が表示されます。他のマシンから実行すると、500エラーが表示され、エラーメッセージは表示されません。

これを処理するための最良のアプローチは何ですか？エラーについて、人間が読める形式でユーザーに伝える必要があります。IISでエラーメッセージをオンにしたくないのは、それが良い習慣ではないからです。

4

4 に答える 4

2

ここにエラーはないと思いますが、ビジネス ルール違反です。

私は両方を区別したいと思います。最初の予期しない状況 (データベース接続の喪失など) と、その後に発生する可能性が高いとわかっているシナリオです。

エラーについては、一般的な方法でユーザーに通知するのが適切だと思います（「予期しないエラーが発生しました」など）。これは、ユーザーが修正できず、詳細な情報を必要としないものであるためです。

一方、ビジネス ルールは、ユーザーが理解し、修正するためのアクションを実行できるものです (ここでは、ユーザー名の制約)。したがって、ユーザーに通知する必要があります。

私が取り組んできたプロジェクトでは、例外のタイプがありますBusinessException。何が問題であったかを示すメッセージとともにスローし、人間が読める形式でレンダリングします。この例外を明示的に try-catch することはしませんが、ハンドラーを使用してそれらを管理します。MVC を使用している場合は、それを実行できる拡張フックがあります。

他のタイプの例外については、スタックトレースをどこかに記録することをお勧めします (つまり、EventViewer) が、ユーザーに詳細を提供しないでください。

この場合、次のようにします。

  • ボタンで名前をチェックして、ユーザーが名前を事前に検証できるようにします。
  • 名前を検証する場所は、アプリケーションのビジネス ロジックを配置する場所によって異なります。DB では、ストアド プロシージャを使用するのが 1 つのアプローチですが、EF を使用している場合、これはデータ アクセスから抽象化する必要があることを意味します。代わりに、LINQ(のようなものを使用して、この検証を自分で作成し、 Context.Users.SingleOrDefault(x => x.Name == name)null またはユーザーを返すかどうかを確認できます。DB 制約が既にあるため、この検証は必要ないと思うかもしれませんが、この方法では、ロジックは残りますアプリケーションのコード。
  • EF からの例外のキャプチャは、SQL エラー コードをチェックして、それが制約違反なのか他のエラーなのかを判断する必要があるため、厄介な場合があります。そして、それを判断したとしても、メッセージをユーザーフレンドリーなものに変換する必要があります.

これがあなたの決定に役立つことを願っています！

于 2012-05-25T13:34:56.053 に答える
1

DbContextを使用している場合は、組み込みの検証をカスタマイズすることにより、一意性を検証できます。このブログ投稿を見てください： http：//blogs.msdn.com/b/adonet/archive/2011/05/27/ef-4-1-validation.aspx 。最後に、その方法を示す例があります。

于 2012-05-25T15:58:53.627 に答える
1

まず、クライアントのサーバーに送信する前に検証を行うことをお勧めします。ユーザーに即座にフィードバックを提供することは良い経験です。

第二に、私がいくつか使用している実際の挿入について考慮できるオプションはほとんどありません。

  1. チェックと挿入を実行し、挿入が成功したことの確認として新しいレコードを返すストア プロシージャを使用します。これは、トランザクションで簡単に実行でき、ストア プロシージャ内のすべての問題を処理できますが、コンパイルされたコードの外側にある機能を使用できるようになりました。
  2. 挿入プロシージャでは、トランザクションで最初に検証して適切に処理する呼び出しをラップし、コンパイルされたコードを提供し、ストア プロシージャのような外部依存関係の複雑さを軽減しますが、そのレイヤーからのトランザクション ロックのタイプにはいくつかの制限がありますが、実行可能です。
  3. 例外を挿入してキャッチし、適切に処理するようにしてください。これは私のお気に入りではありません

の更新について言及しているのを見ませんでしたUserName。この機能を許可する場合、挿入を行っているときと同じ問題が発生するため、更新前にも検証する必要があります。

于 2012-05-25T12:48:14.870 に答える
1

そのためのクライアント側の検証はありません（そのような検証を汎用にする方法はありますか？）

私はいつもそうします。jquery ajax を使用してサーバー ページを呼び出し、そこでデータを確認することができます。これにより、送信ボタンをクリックする前に、ユーザー名が利用できないことをユーザーに知らせます。これにより、ユーザーエクスペリエンスが向上します。このアプローチは、別のサーバー ラウンド トリップを回避します (すべてのフォーム データを含む通常のフォーム ポストとエラーの受信)。

同じ名前のユーザーを挿入しようとすると、サーバーが 500 エラーを返します。

常にコード内の例外をキャッチしてログに記録してください。エラーに関するわかりやすいメッセージをユーザーに表示します。例外のスタックトレースをエンド ユーザーに表示しないでください。ASP.NET を使用している場合は、カスタム エラー ページ機能を利用してください。

于 2012-05-25T13:47:01.570 に答える