4

FK関係をモデル化するクラスがあります。その中に2つのリストがあります。これらのリストには、それぞれ親テーブルと子テーブルの列名が含まれています。これらのリストは、クライアントから私に渡されたものです。FK オブジェクトを作成する前に、次のチェックを (順番に) 行う必要があると思います。

  1. リストが null でないかどうかを確認します。
  2. リストに null が含まれているかどうかを確認します。
  3. リストに重複する列が含まれている場合は?
  4. 両方のリストのサイズは同じです。

したがって、合計 7 つのチェックがあることがわかります。そんなにたくさんのチェックがあっても大丈夫ですか？

これらの多くのチェックを行っても問題ない場合、そのようなケースを処理するパターンはありますか (検証チェックの数が多い場合)?

ダメならどうすればいいですか？これらの条件を契約の一部として文書化し、この契約に違反した場合に API が無意味な結果を生成することに言及する必要がありますか?

編集：基本的に、これら2つのリストを取得して、データベース固有のクエリを作成しようとしています。したがって、このオブジェクトを正しく構築することが重要です。

4

4 に答える 4

3

誰もが言うように、それはあなた次第です。これには、そのような固定/標準のガイドラインはありません。ただし、単純にするために、すべての検証ロジックを 1 か所に配置する必要があります。これにより、読みやすく変更しやすくなります。

あなたが言ったように、提案はすべて、あなたの検証ロジックは非常にビジネス指向のようです..つまり、エンドユーザーはあなたのデータベース構成について気にするべきではありません。クラス名を FKEntity とします。したがって、エンティティの概念に従う場合は、特定のエンティティを検証する検証ロジックを FKEntity.validate() (インターフェイス Validatable を実装) に配置できます...これは、すべての FKEntity タイプ オブジェクトに適用される種類の検証ロジック用です。同じように。また、互いに異なる FKEntity を比較/処理する検証ロジックが必要な場合 (たとえば、値が "x" の FKEntity が 1 つある場合、他のエンティティは "x" を値として持つことはできません。エンティティ リスト全体の永続化を許可しない)、ロジックをサービス レイヤーに配置できます。

Inteface Validatable { void validate() throws InvalidEntityException; }   

Class FKEntity implements Validatable {
  //..
  public void validate() throws InvalidEntityException {
     //your entity specific logic
  }
}

Class FKDigestService {

    public digestEntities() {

      try {
      for(FKEntity e : entityList)
         e.validate();

      //your collective validation logic goes here
      } catch (EntityValidationException e) {//do whatever you want}
    }

}

これにより、2つの利点が得られます。

  1. エンティティ固有の検証ロジックは 1 か所に保持されます (ほとんどのロジックをエンティティ固有のロジックと考えるようにしてください)。

  2. これらのロジックは FKEntity のコレクションがある場合にのみ適用され、単一のエンティティには適用されないため、これらのロジックをエンティティに配置することはできないため、集合ロジックはエンティティ ロジックから分離されています...これはビジネス ロジックであり、検証ロジックではありません。

于 2012-08-06T04:49:53.780 に答える
2

これは複雑な問題であるため、解決策は可能な限り単純にして、さらに複雑で理解しにくくならないようにする必要があります。

私のアプローチは次のとおりです。

いくつかのパブリック メソッド ラッピング プライベート メソッドのような名前を付けてdoAllNeededListsValidationInFixedOrder()、別のプライベート メソッドを作成します。必要な検証ごとにそれぞれ作成します。

また、ofc のような書き込み方法doAllNeededListsValidationInFixedOrderの後には、公開されていなくても、堅実な javadoc が続く必要があります。

パターンを使いたい場合、解決策はそれほど単純ではありません。特定の順序でチェックを要求する基本的なことは、ロットまたはクラスを作成することです-オブジェクトがあるチェックの後、別のチェックの前であることを示す状態のすべて。

したがって、パターンを使用してこれを実現できますState-すべてのチェックをオブジェクトの新しい状態として扱います。

また

Builderオブジェクトを作成するために呼び出されるメソッドの強制的な順序でパターンのようなものを使用できます。基本的には、多くのインターフェイスを使用して、すべての（構築）メソッド（ここでは検証）を異なるインターフェイスから起動し、それらの順序を制御しています。

最初に戻ります-検証メソッドセットを非表示にする、シンプルで十分に文書化され、適切に名前が付けられたメソッドを使用することは、私にとってより良いようです。

于 2012-08-05T21:23:35.397 に答える
2

私はあなたに依存しています。多くのチェックに対する本当の議論はありません。API を開発している場合、これは他のプログラマーにとって非常に便利です。そして、それはあなた自身のプログラムをより信頼できるものにします。

重要なポイントは、1 つのポイントでチェックを行うことだと思います。API には、クリーンでシンプルなインターフェースが必要です。このインターフェイスでは、チェックを行っても問題ありません。これらのチェックの後、すべてが機能していることを確認できます。

小切手を放置するとどうなりますか? どこかで例外がスローされますか、それともプログラムが何かを行うだけですか? プログラムが正常に動作し、予測できないことを行う場合は、チェックを提供する必要があります。そうしないと、事態がおかしくなり始めます。しかし、とにかく例外がスローされる場合は、(私が思うに) チェックを外すことができます。つまり、とにかくプログラムは例外を取得します。

于 2012-08-05T21:24:24.763 に答える
0

これらの多くのチェックを行っても問題ない場合、そのようなケースを処理するパターンはありますか (検証チェックの数が多い場合)?

これらのチェックは、データ変換の観点から取り組めば簡単になります。

  1. List from a client実際には、可能な要素のリストです

  2. List from a client明確に定義されたlist of not duplicating not null elements

  3. この変換は、いくつかの単純な変換に分解できToNonNullますToNonNullList。ToNonDuplicatingList

  4. 最後の要件は、基本的に 2 つのリストからペアの 1 つのリストへの変換です。ToPairs(ListA, ListB)

まとめると次のようになります。

ParentTableColumns = List1FromClient.
    ToNonNull.
    ToNonNullList.
    ToNonDuplicatingList

ChildTableColumns = List2FromClient.
    ToNonNull. 
    ToNonNullList.
    ToNonDuplicatingList

ParentChildColumnPairs = List.
    ToPairs(ParentTableColumns, ChildTableColumns)

クライアントからのデータが有効な場合、すべての変換が成功し、有効な結果が得られます。

クライアントからのデータが無効な場合、変換の 1 つが失敗し、エラー メッセージが生成されます。

于 2016-01-02T15:11:27.867 に答える