構造体を使用して組み込み型の検証を実施する

通常、ドメインオブジェクトには、組み込みの型で表すことができるプロパティがありますが、その有効な値は、その型で表すことができる値のサブセットです。

これらの場合、値は組み込み型を使用して格納できますが、値は常にエントリの時点で検証されるようにする必要があります。そうしないと、無効な値で処理される可能性があります。

これを解決する1つの方法は、組み込み型のstruct単一のprivate readonlyバッキングフィールドがあり、そのコンストラクターが指定された値を検証するカスタムとして値を格納することです。そうすれば、このstructタイプを使用することで、検証済みの値のみを使用することが常に確実になります。

基になる組み込み型との間のキャスト演算子を提供して、値が基になる型としてシームレスに出入りできるようにすることもできます。

例として、ドメインオブジェクトの名前を表す必要がある状況を取り上げます。有効な値は、1〜255文字の文字列です。これを表すには、次の構造体を使用します。

public struct ValidatedName : IEquatable<ValidatedName>
{
    private readonly string _value;

    private ValidatedName(string name)
    {
        _value = name;
    }

    public static bool IsValid(string name)
    {
        return !String.IsNullOrEmpty(name) && name.Length <= 255;
    }

    public bool Equals(ValidatedName other)
    {
        return _value == other._value;
    }

    public override bool Equals(object obj)
    {
        if (obj is ValidatedName)
        {
            return Equals((ValidatedName)obj);
        }
        return false;
    }

    public static implicit operator string(ValidatedName x)
    {
        return x.ToString();
    }

    public static explicit operator ValidatedName(string x)
    {
        if (IsValid(x))
        {
            return new ValidatedName(x);
        }
        throw new InvalidCastException();
    }

    public static bool operator ==(ValidatedName x, ValidatedName y)
    {
        return x.Equals(y);
    }

    public static bool operator !=(ValidatedName x, ValidatedName y)
    {
        return !x.Equals(y);
    }

    public override int GetHashCode()
    {
        return _value.GetHashCode();
    }

    public override string ToString()
    {
        return _value;
    }
}

例が示すツーstringとしてキャストimplicit、これが失敗することはできませんとしてではなくfrom- stringとしてキャストexplicit、これは無効な値のためにスローされますよう、もちろんこれらの両方のことのどちらかでしたimplicitかexplicit。

また、からのキャストによってのみこの構造体を初期化できますstringが、IsValid staticメソッドを使用してそのようなキャストが失敗するかどうかを事前にテストできます。

これは、単純な型で表すことができるドメイン値の検証を実施するのに適したパターンのように思われますが、頻繁に使用されたり、提案されたりすることはありません。その理由について興味があります。

だから私の質問は、このパターンを使用することの利点と欠点は何だと思いますか、そしてなぜですか？

これが悪いパターンだと思われる場合は、その理由と、あなたが感じていることが最良の代替案であることを理解したいと思います。

注：この質問は当初Stack Overflowで質問しましたが、主に意見ベース（皮肉にも主観的）として保留にされました。うまくいけば、ここでより多くの成功を収めることができます。

上は元のテキストで、もう少し考えてみると、保留になる前にそこで受け取った回答に部分的に対応しています。

• 回答で指摘された主なポイントの1つは、特にそのようなタイプが多く必要な場合に、上記のパターンに必要なボイラープレートコードの量にありました。ただし、パターンを守るために、これはテンプレートを使用して大幅に自動化することができ、実際には私にはそれほど悪くないように見えますが、それは私の意見です。
• 概念的な観点から見ると、C＃などの強く型付けされた言語を使用して、強く型付けされた原則を複合値にのみ適用するのではなく、ビルトインタイプ？

これは、標準のML / OCaml / F＃/ Haskellなどのラッパータイプを作成する方がはるかに簡単なMLスタイルの言語ではかなり一般的です。次の2つの利点があります。

• これにより、コード自体が文字列の検証を強制することができます。検証自体を処理する必要はありません。
• これにより、検証コードを1か所にローカライズできます。ValidatedNameeverに無効な値が含まれている場合、エラーがIsValidメソッドにあることがわかります。

IsValidメソッドが正しい場合、を受け取るすべての関数がValidatedName実際に検証済みの名前を受け取っていることが保証されます。

文字列操作を行う必要がある場合は、文字列（の値ValidatedName）を受け取り、文字列（新しい値）を返し、関数を適用した結果を検証する関数を受け入れるpublicメソッドを追加できます。これにより、基になるString値を取得して再ラップするという定型がなくなります。

値をラップするための関連する用途は、その起源を追跡することです。たとえば、CベースのOS APIは、リソースのハンドルを整数として提供することがあります。OS APIをラップして、代わりにHandle構造を使用し、コードのその部分へのコンストラクターへのアクセスのみを提供できます。Handles を生成するコードが正しい場合、有効なハンドルのみが使用されます。

このパターンを使用するメリットとデメリットは何だと思いますか、そしてその理由は何ですか。

良い：

• それは自己完結型です。検証ビットが多すぎると、巻きひげがさまざまな場所に到達します。
• 自己文書化に役立ちます。メソッドがa ValidatedStringを受け取るのを見ると、呼び出しのセマンティクスがより明確になります。
• パブリックメソッド間で複製する必要がなく、検証を1つのスポットに制限するのに役立ちます。

悪い：

• キャスティングの仕掛けは隠されています。これは慣用的なC＃ではないため、コードを読み取るときに混乱を招く可能性があります。
• 投げます。検証に適合しない文字列があることは例外的なシナリオではありません。IsValidキャストの前に行うことは少し厄介です。
• なぜ何かが無効なのかはわかりません。
• デフォルトValidatedStringは有効/検証されていません。

私はより頻繁にこの種のものを見てきましたUserし、AuthenticatedUserオブジェクトが実際に変わるもの、のようなもの。C＃では場違いのように見えますが、これはすばらしいアプローチです。

あなたの道はかなり重く、集中的です。私は通常、次のようなドメインエンティティを定義します。

public class Institution
{
    private Institution() { }

    public Institution(int organizationId, string name)
    {
        OrganizationId = organizationId;            
        Name = name;
        ReplicationKey = Guid.NewGuid();

        new InstitutionValidator().ValidateAndThrow(this);
    }

    public int Id { get; private set; }
    public string Name { get; private set; }        
    public virtual ICollection<Department> Departments { get; private set; }

    ... other properties    

    public Department AddDepartment(string name)
    {
        var department = new Department(Id, name);
        if (Departments == null) Departments = new List<Department>();
        Departments.Add(department);            
        return department;
    }

    ... other domain operations
}

エンティティのコンストラクターでは、FluentValidation.NETを使用して検証がトリガーされ、無効な状態のエンティティを作成できないようにします。プロパティはすべて読み取り専用であることに注意してください-プロパティは、コンストラクターまたは専用のドメイン操作を介してのみ設定できます。

このエンティティの検証は別のクラスです：

public class InstitutionValidator : AbstractValidator<Institution>
{
    public InstitutionValidator()
    {
        RuleFor(institution => institution.Name).NotNull().Length(1, 100).WithLocalizedName(() =>   Prim.Mgp.Infrastructure.Resources.GlobalResources.InstitutionName);       
        RuleFor(institution => institution.OrganizationId).GreaterThan(0);
        RuleFor(institution => institution.ReplicationKey).NotNull().NotEqual(Guid.Empty);
    }  
}

これらのバリデーターは簡単に再利用することもでき、ボイラープレートコードを少なくすることができます。そしてもう一つの利点はそれが読みやすいということです。

値型に対するこのアプローチが好きです。コンセプトは素晴らしいですが、実装についていくつかの提案/不満があります。

キャスティング：この場合、キャスティングの使用は好きではありません。明示的なfrom-stringキャストは問題ではありませんが、(ValidatedName)nameValueとnewの間に大きな違いはありませんValidatedName(nameValue)。だからそれは一種の不必要なようです。暗黙のストリングへのキャストは最悪の問題です。実際の文字列値を取得することはより明示的である必要があると思います。誤って文字列に割り当てられる可能性があり、コンパイラーが「精度の損失」の可能性について警告しないためです。この種の精度の低下は明白です。

ToString：ToStringデバッグ目的でのみオーバーロードを使用することを好みます。そして、そのための生の値を返すことは良い考えではないと思います。これは、暗黙的な文字列への変換と同じ問題です。内部値の取得は明示的な操作である必要があります。構造を外部コードに対する通常の文字列として動作させようとしていると思いますが、そうすると、この種の型を実装することで得られる値の一部が失われます。

EqualsとGetHashCode：構造体はデフォルトで構造的等価性を使用しています。したがって、EqualsおよびGetHashCodeはこのデフォルトの動作を複製しています。あなたはそれらを取り除くことができ、それはほとんど同じものになります。