1

不動産ポータルを構築しています。サービス、マッパー、エンティティがあります。段階では、ユーザーに次のいずれかを許可しています

  1. フォームからプロパティを作成します。
  2. 1 つ以上のプロパティを含むバッチ ファイルをアップロードします。

したがって、彼がフォームを介してプロパティを作成した場合、フォームを検証でき、有効なプロパティである場合は、それをシステムに追加できます。しかし、彼がバッチファイルを介してアップロードする場合、フォームの責任は

  • ユーザーがファイルを提供したことを検証する
  • ファイルの種類は有効です
  • ファイルサイズは許容範囲内です。

この後、ファイルをコントローラーまたはサービスに引き渡す必要があります。

現在、保留中のタスクは

  • ファイルを処理して内容を取得する
  • 内容を検証する
  • 検証された場合は、プロパティを保存するか、エラーを表示します。

では、上記のタスクを担当するのはどの部分でしょうか?

コントローラーが最初のファイル処理を行い、データをサービスに渡す必要があると考えています。これは、コントローラーでフォーム オブジェクトを作成/取得し、コントローラー内でフォームを検証することを意味します。

次のセクションでは、実際にはエンティティのコレクションであるコンテンツを検証します。したがって、この段階では次のようなアイデアがあります

  1. サービスはデータを検証してエンティティを作成し、それらを保存します。
  2. または、サービスは提供されたデータを使用してエンティティを作成し、エンティティの検証関数を呼び出します。
  3. または、サービスは提供されたデータを使用してエンティティを作成しようとし (データをエンティティ コンストラクターに送信します)、データが有効な場合は、エンティティが作成されるか、エラーが生成されます。

上記のアプローチについて私が考えることができる問題は次のとおりです。

  • サービスがデータを検証している場合、それはサービスがエンティティの内部構造を認識していることを意味します。そのため、後でエンティティ構造を更新する必要がある場合は、サービスも更新する必要があります。これにより、ある種の依存関係が導入されます。
  • 2番目のアプローチでは、エンティティが有効でない場合、最初にエンティティを作成する必要はないと思います。
  • 3 番目のアプローチでは、エンティティのコンストラクター内に機能を作成するため、エンティティをデータに依存させます。そのため、エンティティを永続から取得する必要がある場合は、スタブ データを提供する必要があります。

それとも私の考えすぎ??

4

2 に答える 2

1

次のセクションでは、実際にはエンティティのコレクションであるコンテンツを検証します。

ControllerがServiceに送信するContentsは、オブジェクトのグラフ/構造/最も単純な場合のプレーン文字列ですが、ビジネスエンティティのコレクションではありません。

サービスがデータを検証している場合、それはサービスがエンティティの内部構造を認識していることを意味します

サービスの検証とは正確には何ですか?

サービスがデータを検証しているということは、サービスが受信するすべての構造/オブジェクトの不変性を保証することを意味します。

たとえば、F(T)がサービス メソッドで、が3 つの辺を持つ三角形を表すTプロパティを持つ構造体である場合、サービスは不変条件 (各サイトの長さが 0 より大きく、任意の 2 辺の長さの合計がより大きくなければならない)を保証する必要があります。この構造体が逆シリアル化された後、この構造体の 3 番目の辺の長さよりも長くなります。{ A, B, C }

デシリアライザーは、デシリアライズ中に不変条件を保証するためにコンストラクターを使用しないため、この検証を行う必要があります。

これらの検証が完了すると、 Serviceに渡されたすべてのオブジェクトが有効になり、ビジネス レイヤーで直接自由に使用したり、ビジネス レイヤーで認識されるオブジェクト (エンティティなど) に変換したりできます。

エンティティ構造を更新する必要がある場合は、サービスも更新する必要があります。これにより、ある種の依存関係が導入されます。

この依存関係は避けられません。転送オブジェクトエンティティ オブジェクトが分離されているため、それらを変換する方法を知っているマッパーが常に存在します。

サービスはデータを検証してエンティティを作成し、それらを保存します。

私はこれで行きます。サービスは、データを検証し、ビジネス レイヤー オブジェクトに変換し、ビジネス レイヤー関数を呼び出し、変更を保持します。

于 2016-08-01T12:09:24.910 に答える
0

それは、検証している制約の種類によって異なります。

1. notEmpty プロパティ名や最大長などのパラメーター検証。

この場合、検証ロジックを Validator オブジェクトに抽出できます。これは、フォーム (Web フォーム、ファイルのアップロード) を作成する複数のプロパティがある場合に便利です。バリデーターは複数の「クライアント」によって呼び出される可能性がありますが、検証ロジックは 1 つのオブジェクトに保持されます。

2. ビジネス ルールの検証。

私はドメイン モデルを使用することを好みます。このプレゼンテーションの PhoneNumber の例をご覧ください。

于 2013-10-12T01:25:31.467 に答える