使用struct强制验证内置类型

通常，域对象具有可以用内置类型表示的属性，但是其有效值是可以用该类型表示的值的子集。

在这些情况下，可以使用内置类型存储值，但是必须确保始终在输入点验证值，否则我们最终可能会使用无效值。

解决此问题的一种方法是将值存储为自定义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;
    }
}

该示例显示了TO- string投的implicit，因为这可能永远不会失败，但在从- string铸造的explicit，因为这将引发无效值，但当然这些都可能是两种implicit或explicit。

还要注意，只能通过from的强制转换来初始化此结构string，但是可以使用IsValid static方法预先测试这种强制转换是否会失败。

这似乎是强制验证可以用简单类型表示的域值的一种好模式，但是我看不到它经常使用或建议使用，而且我对原因很感兴趣。

所以我的问题是：您认为使用此模式的优点和缺点是什么？为什么？

如果您认为这是一个糟糕的模式，我想了解为什么以及您认为是最佳的选择。

注意：我最初是在Stack Overflow上问这个问题的，但由于主要基于观点（具有讽刺意味的是，它本身具有主观性）而被搁置了-希望它可以在这里获得更多的成功。

上面是原始文本，下面是一些想法，部分是对搁置之前在那里收到的答复的回应：

• 答案提出的主要观点之一是上述模式所需的样板代码数量，尤其是在需要许多此类代码时。但是，为了捍卫这种模式，可以使用模板在很大程度上将其自动化，并且实际上对我来说似乎还不错，但这只是我的观点。
• 从概念的角度来看，使用强类型语言（例如C＃）仅将强类型原理应用于复合值，而不是将其扩展为可以由a实例表示的值，这似乎并不奇怪。内置类型？

这在ML风格的语言（例如Standard ML / OCaml / F＃/ Haskell）中相当普遍，在其中创建包装器类型要容易得多。它为您提供两个好处：

• 它允许一段代码来强制字符串已经经过验证，而不必自己进行验证。
• 它使您可以将验证代码集中在一个地方。如果ValidatedNameever包含无效值，则说明该IsValid方法中有错误。

如果IsValid正确使用该方法，则可以保证任何接收到a的函数ValidatedName实际上都将接收经过验证的名称。

如果需要进行字符串操作，则可以添加一个公共方法，该方法接受一个接受String（的值ValidatedName）并返回String（新值）的函数，并验证应用该函数的结果。这消除了获取基础String值并重新包装它的样板。

包装值的一个相关用途是跟踪其来源。例如，基于C的OS API有时以整数形式提供资源句柄。您可以包装OS API来使用Handle结构，而仅提供对构造函数的访问，以访问代码的那部分。如果产生Handles 的代码正确，那么将仅使用有效的句柄。

您认为使用此模式有什么优点和缺点，为什么？

好：

• 它是自包含的。验证位太多，卷须到达不同的位置。
• 它有助于自我记录。看到一个方法可以ValidatedString使调用的语义更加清晰。
• 它有助于将验证限制在一个位置，而无需在公共方法之间重复。

不好：

• 铸造技巧被隐藏了。它不是惯用的C＃，因此在阅读代码时可能会造成混乱。
• 它抛出。拥有不符合验证条件的字符串并不是一个例外的情况。做IsValid演员之前是一个小unweildy。
• 它无法告诉您为什么有些无效。
• 默认值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字符串转换不是问题，但是(ValidatedName)nameValuenew和new 之间没有太大区别ValidatedName(nameValue)。因此，这似乎是不必要的。隐式字符串转换是最糟糕的问题。我认为获取实际的字符串值应该更加明确，因为它可能会意外地分配给字符串，并且编译器不会警告您可能的“精度损失”。这种精度损失应该是明确的。

ToString：我更喜欢将ToString重载用于调试目的。而且我不认为返回原始值是个好主意。这与隐式到字符串转换的问题相同。获取内部值应该是显式操作。我相信您正在尝试使结构的行为像外部代码的普通字符串一样，但是我认为这样做会使您失去从实现这种类型中获得的一些价值。

Equals和GetHashCode：默认情况下，结构使用结构相等。因此，您Equals和GetHashCode正在复制此默认行为。您可以删除它们，这几乎是相同的事情。