Business Components for Javaには、ビジネス・ロジック層で検証ロジックを定義、実装および実行するためのフレームワークが用意されている。検証フレームワークでは、内部の実装の詳細が隠された、一貫したプログラミング・モデルが提供される。これにより、ユーザーが無効な値をデータベースに入力できないようにする規則に集中できる。
検証は、整合性(またはデータベースの)制約とは異なる。整合性制約は、表の列にビジネス・ルールを定義する宣言である。整合性制約は、表で定義され、表定義の一部として、データベースのデータ・ディクショナリに主として保存される。これによって、すべてのデータベース・アプリケーションに同じ規則が適用される。Business Components for Javaを使用しないクライアントには、(検証の他に)整合性制約を使用できる。
次のプログラムによる手法(Java)または宣言による手法(XML)を使用し、検証ロジックを定義および適用できる。検証に様々なレベルが定義されている場合は、その検証は一貫してこの順序で起動される。
エンティティ属性およびビュー属性のデータ型としてのドメインの使用。(プログラムによる手法)ドメイン・オブジェクトは、コンストラクタ内のデータを検証する。また、ドメイン・オブジェクトの検証メソッドに規則を適用したり、コードを追加して、ビジネス・ロジックを修正できる。ドメインを使用すると、エンティティ・オブジェクト、ビュー・オブジェクト(またはその両方)の全体で属性レベルの検証を共有できる。クライアントのプログラミング方法に応じて、検証はクライアントまたはビジネス・ロジック層で起動される。たとえば、ドメイン型CurrencyでPrice属性を作成するとする。クライアントにドメインがダウンロードされている場合は、ユーザーが適切な通貨を入力していないと、フィールドから移動した時点で、そのことが通知される。ドメインは、属性間で再利用できる。たとえば、CreditCardドメインが頻繁に再利用される場合、検証が必要なすべてのエンティティ・オブジェクトにコードを追加する必要はなく、更新も一度に行える。
エンティティ検証メソッドの編集。(プログラムによる手法)ビジネス・コンポーネント・フレームワークでは、エンティティ・オブジェクトのsetAttribute メソッド(Dept.setLocなど)を作成できる。この場合、属性を設定する前または後に起動される検証を追加できる。セッター・メソッドには、属性値によってのみ影響を受け、頻繁に再利用する必要のない規則を追加する。
validateEntityメソッドへのコードの追加。(プログラムによる手法)ベースのEntityクラスにより、エンティティ・オブジェクトでオーバーライドできるvalidateEntityメソッドが提供される。エンティティ検証は、ある行から別の行へ移動する前に起動される。エンティティ検証は、複数の属性値を検証する場合に便利である。行全体の値が入力されるまで個別のフィールドの検証を行わない場合や、関連付けられているエンティティ・オブジェクトの値を検証する場合などである。たとえば、Salary属性では、役職名、通貨などの別のフィールド値のチェックが必要な場合がある。また、開始日として終了日よりも前の日付を設定する必要がある場合など、日付の範囲をチェックする場合もある。
エンティティ・オブジェクトおよびエンティティ属性に対する検証規則の適用。(宣言による手法)検証規則では、検証の再利用パターンがカプセル化され、適切なパラメータ値を指定することにより、これを使用できる。エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ、ならびにエンティティ属性エディタを使用して、コードを記述せずに単純な規則を定義し、適用できる。すべてのコードを記述するのではなく、ウィザードを使用すると、XMLが生成され、Javaコードを再コンパイルせずに規則をカスタマイズできる。定義済のValidatorタイプを使用することも、独自に定義することもできる。独自のカスタム検証クラスでは、より複雑な規則も実装できる。この場合、クラスをValidatorタイプとして登録し、定義済の規則と同様に適用できる。
コンポジットの定義。(プログラムによる手法)コンポジットによって、ビュー・オブジェクト・レベルでの親子階層の検証が提供される。親のvalidateEntityメソッドが、子を検証する。たとえば、注文がなければ明細品目は発生しない。
ビジネス・コンポーネント・フレームワークは、様々な検証レベルをサポートする。属性、エンティティおよび論理ビジネス・オブジェクトを検証できる。JDeveloperは、データが作成または変更された際に適切なレベルで検証ロジックをコールするが、表にすでに存在しているデータは有効であると仮定する。問合せにより、無効な値(たとえば、検証ロジックが適用される前に入力されたレガシー・データからの値)が含まれた結果セットが返されることがあるが、ユーザーが表に無効な値を入力することはできない。フレームワークでは、最上位レベルのオブジェクトで規則が起動される前に、これに含まれるオブジェクトで規則が起動される。