タグ付けされた質問 「validation」

関数の入力パラメーターを検証するのに最適な場所はどこですか：呼び出し元または関数自体ですか？ コーディングスタイルを改善したいので、この問題のベストプラクティスまたはいくつかのルールを見つけようとします。いつ、何がより良い。 私の以前のプロジェクトでは、関数内のすべての入力パラメーターをチェックして処理していました（たとえば、nullでない場合）。ここで、入力パラメーターの検証は呼び出し側の責任であることをいくつかの回答とPragmatic Programmerの本で読みました。 つまり、関数を呼び出す前に入力パラメーターを検証する必要があるということです。関数が呼び出されるすべての場所。そして、それは1つの質問を提起します：それは、関数が呼び出されるすべての場所でチェック条件の複製を作成しませんか？ null条件だけに興味はありませんが、入力変数（sqrt関数への負の値、ゼロ除算、状態と郵便番号の間違った組み合わせ、またはその他）の検証に興味があります 入力条件をチェックする場所を決定する方法はありますか？ 私はいくつかの議論について考えています： 無効な変数の処理が異なる場合、呼び出し側で検証するのが適切です（たとえば、sqrt()関数-場合によっては複素数を処理したいので、呼び出し側で条件を処理します） チェック条件がすべての呼び出し元で同じ場合、重複を避けるために関数内でチェックすることをお勧めします 呼び出し元の入力パラメーターの検証は、このパラメーターを使用して多くの関数を呼び出す前に1回だけ行われます。したがって、各関数のパラメーターの検証は効果的ではありません 適切なソリューションは、特定のケースに依存します この質問が他の質問と重複していないことを願っています。この問題を検索し、同様の質問を見つけましたが、彼らは正確にこのケースに言及していません。

16 coding-standards  validation  dry 

検証が必要なデータが大量にある場合、検証のみを目的として新しいクラスを作成する必要がありますか、またはメソッド内検証に固執する必要がありますか？ 私の特定の例では、トーナメントやイベント/カテゴリクラス企図：TournamentとEvent、モデルのスポーツ大会や各トーナメントは、1つのまたは多数のカテゴリがあります。 これらのクラスで検証するすべての種類のものがあります：プレイヤーは空である必要があり、一意である必要があり、各プレイヤーがプレイするマッチの数、各マッチが持っているプレイヤーの数、事前に定義されたマッチアップ、およびはるかに大きいなど複雑なルール。 また、クラスを相互に統合する方法など、全体として検証する必要のある部分もあります。たとえば、aのユニタリ検証はPlayer問題なく実行できますが、イベントに同じプレーヤーが2回ある場合、検証エラーになります。 では、これはどうですか？：モデルクラスのセッターや同様のメソッドを使用してデータを追加するときの事前チェックを絶対に忘れて、代わりに検証クラスにそれを処理させます。 だから我々は、のようなものがありますEventValidatorとのEventメンバーとして、そしてvalidate()すべてのメンバーのルールを検証するために、オブジェクト全体を検証する方法に加え、特異な方法を。 次に、有効なオブジェクトをインスタンス化する前に、無効な値を防ぐために検証を実行します。 私の設計は正しいですか？私は何か違うことをすべきですか？ また、検証メソッドを返すブール値を使用する必要がありますか？または、検証が失敗した場合に例外をスローしますか？私にとって最良のオプションは、メソッドを返すブール値であり、オブジェクトがインスタンス化されたときに例外をスローすることです、例えば： public Event() { EventValidator eventValidator = new EventValidator(this); if (!eventValidator.validate()) { // show error messages with methods defined in the validator throw new Exception(); // what type of exception would be best? should I create custom ones? } }

15 java  design  data  validation 

（ActiveRecord）モデルに加えて、常にデータベースレベルで制約を適用しています。しかし、私はこれが本当に必要かどうか疑問に思っていましたか？ 少しの背景 私は最近、モデルの基本的な自動タイムスタンプ生成方法を単体テストする必要がありました。通常、テストはモデルのインスタンスを作成し、検証なしで保存します。ただし、テーブル定義でnullにできない他の必須フィールドがあります。つまり、ActiveRecord検証をスキップしてもインスタンスを保存できません。だから私はdb自体からそのような制約を削除し、ORMにそれらを処理させる必要があるかどうかを考えていますか？ db、imoの制約をスキップした場合に考えられる利点 - データベースを移行することなく、モデル内の検証ルールを変更できます。 テストで検証をスキップできます。 考えられる不利益は？ ただし、ORM検証が失敗またはバイパスされる可能性がある場合、データベースは制約をチェックしません。 どう思いますか？ 編集このケースでは、データベースからモデルを生成するYii Frameworkを使用しているため、データベースルールも生成されます（ただし、生成後はいつでも記述できます）。

13 database  orm  validation  dry 

「検証が階層化アーキテクチャのどこに属しているのかを尋ねる別の質問ではありませんか？！？」ええ、はい、しかし、これがこの問題に対する少し異なる見解になることを願っています。 私は、検証は多くの形式を取り、コンテキストベースであり、アーキテクチャの各レベルで異なると固く信じています。これが投稿の基礎です。各レイヤーで実行される検証のタイプを識別するのに役立ちます。また、よくある質問は、承認チェックの場所です。 サンプルシナリオは、ケータリングビジネスのアプリケーションからのものです。日中定期的に、運転手は、トラックを現場から現場へ移動する間に蓄積した余分な現金をオフィスに引き入れることができます。このアプリケーションでは、ユーザーはドライバーのIDと金額を収集することにより、「キャッシュドロップ」を記録できます。関連するレイヤーを説明するスケルトンコードを次に示します。 public class CashDropApi // This is in the Service Facade Layer { [WebInvoke(Method = "POST")] public void AddCashDrop(NewCashDropContract contract) { // 1 Service.AddCashDrop(contract.Amount, contract.DriverId); } } public class CashDropService // This is the Application Service in the Domain Layer { public void AddCashDrop(Decimal amount, Int32 driverId) { …

13 domain-driven-design  validation  layers 

コードの別の部分が正しくコーディングされていない場合に備えて、無駄な例外処理を実装することをお勧めしますか？ 基本的な例 単純なものなので、私は皆を失うわけではありません:)。 データベースから抽出されたデータを人の情報（名前、住所など）を表示するアプリを書いているとしましょう。私がUI部分をコーディングしている人で、他の誰かがDBクエリコードを書いているとしましょう。 ここで、アプリの仕様で、人の情報が不完全な場合（データベースに名前がないなど）、クエリをコーディングしている人が、不足しているフィールドに「NA」を返すことでこれを処理する必要があると考えているとします。 クエリのコーディングが不十分で、このケースを処理できない場合はどうなりますか？クエリを作成した人が不完全な結果を処理し、情報を表示しようとすると、コードが空のものを表示する準備ができていないため、すべてがクラッシュするとどうなりますか？ この例は非常に基本的なものです。私はあなたのほとんどが「あなたの問題ではない、あなたはこのクラッシュの責任を負わない」と言うと信じています。ただし、クラッシュするのは依然としてコードの一部です。 もう一つの例 今、私がクエリを書いている人だとしましょう。仕様は上記と同じではありませんが、「挿入」クエリを作成する人は、データベースに人を追加するときにすべてのフィールドが完全であることを確認して、不完全な情報を挿入しないようにする必要があります。UIの人に完全な情報を提供するために、「選択」クエリを保護する必要がありますか？ 質問 仕様に「この人がこの状況を処理する責任者である」と明示的に述べていない場合はどうなりますか？第三者が別のクエリ（最初のクエリに似ていますが、別のDB上にある）を実装し、UIコードを使用してそれを表示しますが、コードでこのケースを処理しない場合はどうなりますか？ 私が悪いケースを処理することになっていない場合でも、起こりうるクラッシュを防ぐために必要なことをすべきですか？ 私はここで衝突を解決していないので、「（彼）がクラッシュの原因である」などの答えを探していません。私の責任ではない状況からコードを保護する必要があります処理する？ここでは、単純な「空の場合は何かを行う」で十分です。 一般に、この質問は冗長な例外処理に取り組んでいます。私がそれを求めているのは、私がプロジェクトで一人で作業するとき、「万が一に備えて」何か間違ったことをして、悪いケースを通過させるために、連続する関数で同様の例外処理を2〜3回コーディングする可能性があるためです。

12 language-agnostic  validation  exception-handling 

ビューモデルでIValidatableObjectを実装し、カスタム検証を追加できるようにするMVCの拡張ポイントが気に入っています。 このコードを唯一の検証ロジックにして、コントローラーを無駄のないものにしようとしています。 if (!ModelState.IsValid) return View(loginViewModel); たとえば、ログインビューモデルはIValidatableObjectを実装し、コンストラクターインジェクションを介してILoginValidatorオブジェクトを取得します。 public interface ILoginValidator { bool UserExists(string email); bool IsLoginValid(string userName, string password); } ビューモデルにインスタンスを注入するNinjectは、実際には一般的な慣行ではないようです。 これは良いアプローチですか？より良いものはありますか？

12 architecture  asp.net-mvc  dependency-injection  validation  single-responsibility 

私はしばらくこの問題について考えていましたが、他の開発者から意見を聞きたいと思います。 私は非常に防御的なスタイルのプログラミングをする傾向があります。私の典型的なブロックまたはメソッドは次のようになります。 T foo(par1, par2, par3, ...) { // Check that all parameters are correct, return undefined (null) // or throw exception if this is not the case. // Compute and (possibly) return result. } また、計算中に、参照解除する前にすべてのポインターをチェックします。私の考えは、バグがあり、どこかにNULLポインターが表示される場合、私のプログラムはこれをうまく処理し、単純に計算の継続を拒否するということです。もちろん、ログまたはその他のメカニズムのエラーメッセージで問題を通知できます。 もっと抽象的に言えば、私のアプローチは if all input is OK --> compute result else --> do not compute …

12 validation  user-interaction 

私はクリーンについて研究しており、その結果、ソフトウェアの設計と作成の方法について、かなり劇的に再考しています。 しかし、私がまだ取り組んでいることは、「一部のアイテムへの更新の保存時、最初の読み込みなど、表示/編集する権限のあるアイテムのすべてのリスト、このアイテムがリストにあることを確認するなどのビジネスルールです。そして、アイテムカテゴリは現在使用できないようにロックされていません（および他のルールなど） "。それは（複雑だが非定型ではない）ビジネスルールであり、ビジネスロジックをプッシュするのではなく、アプリケーションドメインで処理する必要があるためdb / persistenceレイヤー。 ただし、これらの条件を効率的にチェックするには、すべてのデータをアプリケーションドメインにロードするのではなく、巧妙に作成されたdbクエリで処理するのが最善のようです... 時期尚早な最適化なしで、推奨されるアプローチまたはこの質問を扱っているボブおじさんの記事は何ですか？または、「問題になるまでドメインで検証する」と言いますか？ 最も基本的な使用例以外の良い例やサンプルを見つけるのに苦労しています。 更新： みなさん、こんにちは。返信ありがとうございます。私はもっ​​と明確で、長い間（主にWebアプリ）のソフトウェアを書いていて、まとめて記述したすべてのトピックを確実に経験して同意しているはずです（バックエンドで検証し、クライアントデータを信頼せず、一般的に言って）必要な場合にのみ生の効率を追跡しますが、利用可能な場合はdbツールの強みなどを認識し、「まとめて投げる」という開発者の学習ライフサイクルを経て「N層アプリケーションで巨大な脂肪コントローラーを構築する」コードのトレンド、そして今は基本的にクリーンで単一の責任のスタイルなどを非常に気に入って調査しています。最近のいくつかのプロジェクトの結果として、プロジェクトが進化し、クライアントの要件がさらに明らかになるにつれて、非常に不格好で広く分散したビジネスルールに発展しました。 特に、クライアント向けのREST APIと内部使用機能のためのREST APIを構築するコンテキストでクリーンスタイルアーキテクチャを検討しています。この場合、ビジネスルールの多くは、ネットで目にするすべての例よりもはるかに複雑になる可能性があります。（Clean / Hexアーキテクチャの開発者自身によっても）。 だから私は、CleanとREST APIがどのように共存するかについて本当に質問しました（そして明確に述べられなかった）と思います、ここで最近見られるほとんどのMVCには受信リクエストバリデーターがあります（たとえば。 「検証」ルールはそれほど「50文字未満の文字列ですか」ではなく、「このユーザーは、このユーザーケース/インタラクターを呼び出して、関連するオブジェクトが現在チームXによってロックされている場合、このデータのコレクションに対してこの操作を実行できますか？」月末までなど」...ビジネスドメインオブジェクトやドメインルールが多数適用される、非常に複雑な検証。 これらのルールを特定の種類のValidatorオブジェクトタイプにスピンアウトして、各ユースケースインタラクター（FluentValidatorプロジェクトからインスピレーションを得たものの、より多くのビジネスロジックとデータアクセスを伴う）に付随させる必要があります。それらの検証をゲートウェイ（間違っていると思います）などに配置します。 参考までに、このようないくつかの記事を書きますが、Mattiaは検証についてあまり説明していません。 しかし、私の質問への短い答えは、私が受け入れた答えに非常に似ていると思います：「それは決して簡単なことではなく、それは依存します」。

12 clean-code  domain-model  validation  business-rules 

特定のプログラム用のインターフェイスを作成しようとすると、通常、検証されていない入力に依存する例外をスローしないようにします。 よくあることは、次のようなコードを考えたことです（これは単なる例であり、実行する機能は気にしないでください（Javaの例））。 public static String padToEvenOriginal(int evenSize, String string) { if (evenSize % 2 == 1) { throw new IllegalArgumentException("evenSize argument is not even"); } if (string.length() >= evenSize) { return string; } StringBuilder sb = new StringBuilder(evenSize); sb.append(string); for (int i = string.length(); i < evenSize; i++) { sb.append(' …

11 design  design-patterns  programming-practices  performance  validation 

私たちはいくつかのコードでPexを実行しており、いくつかの良い点を示してきました（悪い点はありますが、本番環境に到達する前にそれらを示しています！）。 ただし、Pexの優れた点の1つは、問題の検出を必ずしも停止する必要がないことです。 見つかった1つの領域は、文字列を渡すときに空の文字列をチェックしていなかったことです。 そこで変更しました： if (inputString == null) に if (string.IsNullOrEmpty(inputString)) // *** それは最初の問題を修正しました。しかし、その後、Pexを再度実行すると、次のことが決定されました。 inputString = "\0"; 問題を引き起こしていました。その後 inputString = "\u0001"; 私たちが決定したのは、遭遇// ***した場合にデフォルトを使用でき、他の奇妙な入力によって引き起こされた例外を見て喜んでいるということです（そしてそれを処理します）。 それで十分ですか？

11 validation  strings  defensive-programming 

誰もがWindows Workflow FoundationをBusinessRules / Validationエンジンに正常に使用したかどうか、またはこれに関するサンプルコードや記事を知っているかどうか疑問に思っていました。 以前に使用したことがある場合、それについてどう思いますか？他のBusinessRule / Validationシステムと比較してどうですか？ 私は次のようなルールを考えています if (A, B, and C) AllowAccess(); または if (Value between X and Y) return true;

11 enterprise-architecture  validation  business-rules  workflow-foundation 

私は、管理者がフィールドを含むフォームを定義できるシステムに取り組んでいます。定義されたフォームは、システムにデータを入力するために使用されます。フォームは、GUIを介して人間が入力する場合もあれば、別のシステムから報告された値に基づいて入力される場合もあります。 各フィールドについて、管理者はフィールドに許可される値を制限する検証ルールを定義できます。検証ルールは、「フィールドに入力された値はTrueまたはFalseである必要があります」から「フィールドに入力された値はデータベースのテーブルBの列Aに存在している必要があります」まで、任意です。管理者はいつでもフィールドの検証ルールを変更できます。 このシナリオでは、各フィールドが正しく入力されていることを検証するのに最も適した場所は何だと思いますか？私は現在、主に2つのアプローチを考えています。 オプション＃1：ドメインモデルで検証する 各フィールドオブジェクトには、管理者が指定した検証ルールが含まれます。Fieldオブジェクトには、IValidatorへの参照も含まれます。フィールドの値を設定しようとすると、フィールドは指定された値と検証ルールをIValidatorに渡します。指定された値が有効でない場合、ValidationExceptionがスローされ、他のシステムへのGUI /インターフェイスで適切に処理されます。 長所： 検証ルールに違反するフィールドが誤って割り当てられたフィールドに対する強力な保護 短所： データアクセスレイヤーは、検証をバイパスし、現在の検証ルールに違反するフィールドを構築できる必要があります。管理者がフィールドの入力規則を変更しても、何年も前に入力されたフォームをレンダリングするときなど、古いデータに基づいてフィールドオブジェクトを構築できる必要があります。これは、フィールドを保存するたびに現在の検証ルールを保存することで解決できる可能性があります。 この設計では、フィールドモデルはIValidatorを介してデータアクセスレイヤー/リポジトリに間接的にリンクしています。ドメインモデルへのサービス/リポジトリの挿入は、一般的には嫌われているようです。 オプション＃2：サービスで検証する フィールドの値を設定するすべての試行が、検証ルールが確実に実行されるサービスを通過するようにしてください。検証ルールに違反している場合は、ValidationExceptionをスローします。 もちろん、以前はDBに永続化されていたFieldオブジェクトを作成する場合、データアクセス層はサービスを使用しません。 長所： 「サービス/リポジトリをドメインモデルに挿入しない」という考え方に違反していない。 フィールドを永続化するときに、現在の検証ルールを永続化する必要はありません。サービスは、フィールドの現在の検証ルールを単純に検索できます。履歴データを見ると、フィールドの値は変更されません。 短所： サービスを使用してフィールド値を設定する必要のあるすべてのロジックが実際にそうであるとは限りません。私はこれを大きな欠点だと考えています。誰かが「thisField.setValue（thatField.getValue（））」を書いているだけで、thisFieldの検証ルールに違反する可能性があります。これは、データアクセスレイヤーがフィールドを永続化しようとしているときに、フィールドの値が入力規則と一致するようにすることで軽減できる可能性があります。 私は現在、オプション＃2よりもオプション＃1を好みます。これは主にこれをビジネスロジックと見なしており、オプション＃2がシステムに不正なデータを導入するリスクが大きいと感じているためです。どちらのオプションを選択しますか、またはこのシナリオに適合する、説明した2つのオプションよりも優れた別のデザインはありますか？ 編集（検証の複雑さ） 現在のところ、検証ケースは比較的単純です。フィールド値は、数値、日付、時刻付きの日付、またはデータベース列の既存の値である必要があります。ただし、時間の経過とともに複雑さが徐々に増加すると思われます。たとえば、検証ソリューションは国際化を念頭に置いて構築する必要があります。日付などはロケール固有の構文で入力できます。 ここでは、オプション1に進むことを決定しました。ドメインモデルに多くの責任を割り当てないように注意してください。同様の状況に直面している人は、関連する質問を確認することもできます。階層化アーキテクチャでの検証と承認およびデータ入力検証-どこですか？いくら？。

10 design-patterns  architecture  domain-driven-design  validation 

アヒルのタイピングについて： アヒルの型付けは、メソッドと関数の本体の引数の型を常にテストするのではなく、ドキュメント、明確なコード、および正しい使用を確実にするためのテストに依存することによって支援されます。 引数の検証について（EAFP：許可よりも許しを求める方が簡単です）。ここからの適応例： ...それを行うにはよりpythonicと考えられています： def my_method(self, key): try: value = self.a_dict[member] except TypeError: # do something else これは、コードを使用する他のユーザーが実際の辞書やサブクラスを使用する必要がないことを意味します。マッピングインターフェースを実装する任意のオブジェクトを使用できます。 残念ながら、実際にはそれほど簡単ではありません。上記の例のメンバーが整数の場合はどうなりますか？整数は不変です。そのため、それらを辞書のキーとして使用することは完全に合理的です。ただし、シーケンス型オブジェクトのインデックス付けにも使用されます。メンバーが偶然整数の場合、例2ではリストと文字列、および辞書を通過できます。 断定的なプログラミングについて： アサーションは、プログラムの内部状態がプログラマが期待したとおりであることを確認する体系的な方法であり、バグをキャッチすることを目的としています。特に、コードの記述中に行われた誤った仮定や、他のプログラマによるインターフェイスの悪用をキャッチするのに適しています。さらに、プログラマーの想定を明確にすることで、インラインドキュメントとしてある程度の役割を果たすことができます。（「明示的は暗黙的よりも優れています。」） 上記の概念は競合する場合があるため、データの検証をまったく行わないか、強力な検証を行うか、またはアサートを使用するかを選択するときは、次の要因を考慮します。 強力な検証。強力な検証とはApiError、たとえばカスタム例外を発生させることです。関数/メソッドがパブリックAPIの一部である場合は、引数を検証して、予期しないタイプに関する適切なエラーメッセージを表示することをお勧めします。タイプをチェックすることで、のみを使用することを意味するのではなくisinstance、渡されたオブジェクトが必要なインターフェース（ダックタイピング）をサポートするかどうかも確認します。APIをドキュメント化し、予想されるタイプを指定し、ユーザーが関数を予期しない方法で使用する可能性がある場合、想定を確認すると安全です。私は通常使用isinstanceし、後で他のタイプやアヒルをサポートしたい場合は、検証ロジックを変更します。 断定的なプログラミング。私のコードが新しい場合、私はアサートをたくさん使います。これに関するあなたのアドバイスは何ですか？後でコードからアサーションを削除しますか？ 私の関数/メソッドがAPIの一部ではないが、自分で記述、調査、テストしていない他のコードに引数の一部を渡す場合、呼び出されたインターフェイスに従って多くのアサーションを実行します。これの背後にある私のロジック-私のコードでよりよく失敗し、スタックトレースのどこかで10レベル深く、理解できないエラーが発生するため、多くのデバッグを行い、とにかくアサートをコードに追加する必要があります。 型/値検証をいつ使用するべきか、または使用しないべきかについてのコメントとアドバイスは断言しますか？質問の構成が最適ではないため申し訳ありません。 たとえばCustomer、SQLAlchemy宣言モデルである次の関数を考えてみます。 def add_customer(self, customer): """Save new customer into the database. @param customer: Customer instance, whose id is None @return: merged into global session customer …

10 python  validation  assertions  duck-typing 

クエリサービスを使用してデータを取得し、コマンドサービスを使用してコマンドを送信するASP.NET MVCアプリケーションがあります。私の質問は、コマンド部分についてです。 リクエストが届くと、コマンドサービスはコマンドディスパッチャーを使用して、指定されたコマンドハンドラーにコマンドをルーティングします。このコマンドハンドラーは最初にコマンドを検証し、すべてが許容できる場合はコマンドを実行します。 具体例：AddCommentToArticleCommandHandlerは、ArticleId、CommentText、EmailAddressを持つAddCommentToArticleCommandを受け取ります。 最初; -記事が存在するかどうかを確認します-記事が閉じていないかどうかを確認します-コメントテキストが20〜500文字で入力されているかどうかを確認します-電子メールアドレスが入力されており、有効な形式であるかどうかを確認します この検証をどこに置くか疑問に思っていますか？ 1 /コマンドハンドラ自体。ただし、他のコマンドハンドラで再利用することはできません。 2 /ドメインエンティティ内。しかし、ドメインエンティティはリポジトリやサービスを認識していないため、必要な検証を実行できません（記事が存在するかどうかを確認できません）。ただし、一方で、エンティティにロジックが含まれていない場合は、DDDの原則に従っていない単純なデータコンテナーになります。 3 /コマンドハンドラーはバリデーターを使用するため、検証を他のコマンドハンドラーで再利用できます。 4 /その他のメカニズム？ この特定の例の一連の責任と、その中で役割を果たすオブジェクト（エンティティ、リポジトリなど）を探しています。 コマンドハンドラーからリポジトリまで、これをどのように実装するかについてのアイデアはありますか？

10 c#  architecture  domain-driven-design  validation  cqrs 

連絡先フォームなどを介してユーザーからの入力を検証するときに、クライアント側とサーバー側の両方の検証手法を並べて使用していますか？ もしそうなら、それは本当に必要ですか？あなたはエンジニアリングを超えていますか？

10 web-development  validation