14

ベルトとブレース (サスペンダー)アプローチをプログラミングに、特にデータ検証に使用することは良い習慣であるかどうか疑問に思っていました。これは、次の例から生じました。

フォームを作成していて、すべてのフィールドにリスナーを追加しました。これOKは、フォーム内のすべてのフィールドに有効な値がある場合にのみボタンが有効になることを意味します。OK次に、ボタンがクリックされたときに実行されるコードを書いていました。

私の悲観的な側面は、ベルトとブレースが誰にも害を及ぼすことはなく、フォームロジックにバグがある場合に備えてフォームを再度検証しても害はないと判断しました。

しかし、検証が失敗した場合に何を入力すればよいかわかりませんでした。私がこのようなことをすると:

if (! form.isValid()) {
  displayErrorMessage();
}

次に、決して表示されるべきではないエラー メッセージを表示するコードを作成する必要があります。将来このコードを保守する人は、理論的には不要な対話について心配し、混乱する可能性があります。私が最後に望んでいるのは、なぜこの特定のダイアログが表示されないのか疑問に思っている人です。

スケールの反対側のオプションは次のとおりです。

if (! form.isValid()) {
  throw new RuntimeException("This should never happen!");
}

率直に言って、私はそれを入力することさえ汚いと感じますが、おそらく私が見逃したそれを使用する正当な理由があります.

だから最終的に私は次のようになりました:

assert form.isValid();

ただし、その欠点は、実行時にブレースが存在しないため、実際にはベルトとブレースではないため、コードにバグがある場合、フォームのズボンがそのまま落下することです。

だから余計な検証をするべきではないのかもしれませんが、それでも害はないと思っている部分があります。

同様の状況であなたが何をしているのかを聞くことに興味があります。

編集:質問は、フォームが有効なデータを返すことを保証するための最良の方法は何かを尋ねています。フォームの出力は、データベースなどに入る前に再度検証されると仮定します。)

4

9 に答える 9

5

私はあまり UI の仕事をしていませんが、最近、非常に似たようなことをしていることに気づきました。ベルト (変更されるたびに各コントロールを検証) とブレース (チェックは OK_Click で再度有効) の両方を残しました。

将来の変更がコントロールの検証に失敗した場合、[OK] ボタンをクリックするとキャッチされるという理由で、両方を残しました。

私の頭の中では、OK のチェックが本当の検証であり、コントロールごとの検証は、ユーザー エクスペリエンスを向上させる砂糖です。

とは言っても、あまり考えたことはありませんし、UI の作業を行うこともあまりありません。

于 2009-04-20T12:07:19.703 に答える
5

私の経験から、「念のため」のコードは、遅延プログラミングの兆候である場合があります。つまり、基本的に機能するソリューションを見つけましたが、それが常に機能するかどうかはわかりません。そのため、「念のため」コードを再確認します。ロケット船を月に飛ばさない場合、この種のことは比較的無害ですが、それでも非常に悪い習慣になる可能性があります.

私の (ロケット船ではない) ビジネス アプリケーションでは、常にエラー ログとわかりやすいメッセージを入れて、ユーザーがわかりやすいメッセージをできるだけ頻繁に見ないように、問題を最後まで考えようとします。問題が発生した場合、コードがあらゆる種類の不必要なチェックで散らかっていないため、問題を修正することができます。

于 2009-04-20T13:05:41.857 に答える
1

また、二重検証は誰にも害を及ぼすことはなく、セキュリティを向上させるだけだとも言えます。

また、ビジネスロジックについても指摘したいと思います。これは Winforms アプリケーションだと思いますが、原則は Web にも当てはまります。UI はビジネス ロジックを強制するべきではありません。そこに検証を入れても問題ありませんが、ビジネス ロジックにも含める必要があります。

于 2009-04-20T12:11:11.893 に答える
1

他に何をするにしても、データの破損を防ぐために、予期しない状態をログに記録し、何らかの方法でプログラムを失敗させるようにしてください。個人的には、エラーが予想されない場合には、これで十分であると思います。

于 2009-04-20T12:13:39.750 に答える
1

Web (しゃれは意図されていません) プログラミングでは、実際に実行されているクライアント側の検証に依存できないため、常にこのアプローチを採用します。狡猾なユーザーは、クライアントをシミュレートしてデータをサーバーに送り返すフォーム ポストまたは URL を作成できます。

スタンドアロン アプリでは、それはあまり明確ではありません。検証が行われている場所に依存することをお勧めします。たとえば、検証が UI ではなくビジネス ロジックで実行される場合、検証は毎回実行する必要があります。関心の分離を使用すると、ビジネス ロジックは UI に依存して検証を行うべきではありません。結局、ビジネス ロジックは、典型的な GUI、Web アプリ、または API からも呼び出すことができます。

私が提案したいことの 1 つは、UI で検証ロジックを 2 倍にするのはおそらくやり過ぎだということです。ただし、下層のレイヤーから発生するエラーを処理できる必要があります。この場合、検証からエラーが発生する可能性があります。

于 2009-04-20T12:15:07.173 に答える
1

私の同僚は通常、「念のため」入力を二重検証します。それは、一緒に働く人や、コードを保守する必要がある人に大きく依存すると思います。常に二重検証を行うと、彼らはあなたが何をしているかをすぐに把握できます。時々だけ二重検証を行うと、混乱する可能性があります。同僚の習慣について相談した方がよいでしょうか。1 人または非常に少人数のグループで作業する場合は、入力内容を二重に検証しても問題ないでしょう。

私があなたのコードを引き継ぐとしたら、おそらく重要なことは、常に両方の場所に検証を入れるか、絶対に入れないかのいずれかの規則に従うことだと思います。少なくとも私は迷うことはありませんでした。

編集:Webプログラミングに関する限り、入力がサーバーに送信される前に検証するためにjavascriptが一般的に使用されます。ユーザーが JavaScript をオフにしてその検証を回避できるため、明らかにこれでは十分ではありません。その場合、サーバー側の検証が必要になります。ユーザーが悪意を持って、または誤って検証の最初の行を回避する可能性がある場合は、バックエンドでも再確認することが不可欠です。これは、Java、C# などではそれほど問題ではないと思います。

于 2009-04-20T12:04:14.877 に答える
0

ベルトとブレースは良い習慣ではないと思います。

宇宙船ソフトウェアなどの場合のように、極端な信頼性が必要な場合、それを保証する方法は、並列に実行され、すべて同じ入力が提供され、すべてが同じ出力を提供することが期待される複数の異なる実装を提供することです。明らかに、それはベルトとブレースではなく、別のものです.

極端な信頼性が問題にならない場合、ベルトとブレースは実際には、自分で発見した方法で物事を複雑にするだけです.

アサーションはバグを見つけてコードを文書化することを目的としているため、最終的に得られたアサーションは最善の方法です。これはまさに目の前の状況で起こっていることです。アサーションは、フォームのどこかにバグがあり、アサーションは本質的に、コードのこの時点でフォームの有効性がすでに処理されていることを期待しているという事実を文書化しています. また、このバグが発生する可能性は、アプリケーションのテスト段階で排除する必要があるため、本番環境では決して発生しないようにする必要があります。これは、アサーションの目的と使用目的と同じです。

ベルトとブレースのパラダイムが本当に好きな場合は、アサーションをベルトとブレースのスキームの一部と見なすことができますが、正しいコンテキストであるtest . このアサーションは、コードの他の場所ですべての適切なテストを実行したことを保証するため、テスト中の帯と中括弧です。

于 2014-12-23T14:55:52.413 に答える