2013-08-19 10 views
16

私はこの問題に直面している唯一の人ではないと確信していますが、今まで解決策を見つけることができません。問題は次のとおりです。検証用に使用するデザインパターン

レガシーシステムからすべてのクライアントがそれを使用しているWebサービス(私は何も制御できず、変更できません)を公開しました。私はWebサービスからのリクエストを受け取り、オブジェクトは非常に複雑ですが、例のために、Object B、Object Cなどのいくつかの他のオブジェクトを含むWebサービス呼び出しからオブジェクトAを受け取り、さらにオブジェクトB & Cには、いくつかのプリミティブデータ型およびその他のオブジェクトも含まれています。私の問題は、オブジェクトA(すべてのオブジェクトとサブオブジェクトを含む)全体を検証したいのですが、ここではデザインパターンをお勧めします。第二に、ここでの主なポイントは、Webサービスからさまざまな種類のオブジェクトAを取得できることです。私が実際にオブジェクトAの異なるタイプによって意味することは、オブジェクトAがクライアントに依存するということです。つまり、一部のクライアントは、オブジェクトBを含むオブジェクトにデータを埋め込まずにオブジェクトAを送信します。クライアントに基づいてオブジェクトAを検証する必要があります(一部のクライアントにはオブジェクトBが含まれている必要があり、オブジェクトBにはいくつかの要素が必要です)。言い換えれば、私はクライアントABCがオブジェクトBのフィールドabcを文字列型にし、最大長を25文字にしたいということを教えてくれるような、そのフィールドにデータを格納することは必須です。

私が実行したいと思いますいくつかの検証は、データ型のためのいくつかのオブジェクト(オブジェクトBを言う)、特定のフィールドの長さのフィールドを確認する

で、このクライアントのために必要なフィールドであるか、それがオプションであるなどなど...

具体的な実例は非常に便利です。

この特定の例のオブジェクトAの構造は次のとおりです。

public class A 
    { 
     private B objectB; 
     private C objectC; 
     // and so on 
    } 

    public class B{ 
     private E objectE; 
     private String name; 
     private int age; 
     // and so on 
    } 

    public class C 
    { 
     private F objectF; 
     private String address; 
     private String country; 
    } 

    public class E 
    { 
     // Members here 
    } 

    public class F 
    { 
     // Members here 
    } 

P.S:一般的な理解のためにクラスとメンバーに任意の名前を付けました。 Oはい私はここでJavaを使用していると言及するのを忘れていましたが、デザインの原則やパターンをどの言語にも適用できるので、実際には問題になりません。あなたからすぐに聞くことを望んでいます。:)

+1

検証はさまざまな方法で行うことができ、非常に意見に基づいています。 [戦略パターン](http://en.wikipedia.org/wiki/Strategy_pattern)を見てください。 – Bart

+0

ストラテジーパターン以外の方法をお勧めしますか? –

+0

VisitorとFactory/AbstractFactoryの組み合わせを使用することをお勧めします。ファクトリは、特別なルールを持つクライアントタイプ別に任意のバリデータクラスを作成できます。ビジターカーは、バリデータークラスを使用して構造体全体を検証します。 –

答えて

6

検証はクロスカッティングの問題です。いくつかの方法があり、いくつかのデザインパターンを実装することができます。

Asp.netでは、属性を介して処理が行われています.Java Springでは、アノテーションを使用して、コードをきれいにし、読みやすく保守しやすくしています。

さまざまなアプローチを見つけることができます。これらのフレームワークのアプローチは、次の点に留意してください。コードのメンテナンス、読みやすさ、クリーンなコードです。

銀色の弾丸はありません。あなたのコードで検証を書くことさえできます。

+0

ここでは非常に良い点を指摘しています(これは完全に忘れています)、検証はクロスカッティングの問題です。ありがとうございました。ビジネスオブジェクトやオブジェクトに検証コードを書くと、コードが乱雑になりませんか?私はそれが単一の責任原則に違反すると思います、あなたは何を言いますか? –

+1

ええ、妥当性検査はクロスカッティングの問題ですが、ロギングのように、時には避けることができません。あなたが注意を払う必要があるのは、あなたのコードの正しさ、きれいで、読みやすく、反復性がなく、メンテナンス可能なことです。 – DarthVader

+0

戦略パターン以外のデザインパターンを教えてもらえますか?コードをきれいにして、読みやすく保守しやすいように努めていますが、DRYの原則にも従っていますが、私が手を汚さなければならない点に達していると思います。:) –

0

各クラスはそれ自身を検証する方法を知っている必要があります。 .Validate()メソッドを持つインターフェース(IValidatableなど)から各クラスを派生させることができます。オブジェクトAの.Validate()を呼び出すと、それ自体を検証し、すべての子に対して.Validate()を呼び出します。それらの子供は同様の方法で自分自身を検証することができます。

これはコマンドパターンの本当に単純なバージョンだと思います。並べ替え

また、クラスに追加できる検証ツールを作成することもできます。バリデーターは、電子メールアドレス、正規アドレスなどを検証する方法を知ることができます。これは基本的に、必要なツールのみを含むクラスに添付するツールボックスを作成するので、もう少し拡張可能です。

+3

はい、これは当初、各クラスが独自の検証を担当すると考えていましたが、この単一責任の原則を破ると、実際のコードはビジネスコード。これについての考えは? –

+0

短い答え:それは依存しています。ドメインドリブンデザインを使用した場合は、設定者のすべてのプロパティを検証できます。これは、単一の責任について心配している場合は確かに安全な方法です。私はValidatorの戦略シナリオを使うことで、あなたはまだ安全だと思います。バリデーターはバリデーションを行う責任があります。検証するオブジェクトによって参照されることがあります。 –

関連する問題