Question

我不确定我的问题是什么，但我会尝试解释。

考虑到域模型中的每个类型都将成为规则或验证（或其他）策略，在数据库上持久保存这些验证器的问题是什么？

例如：

有以下模型

public Class Contract
{
    ...
    public ContractType Type {get;set;}

    public bool Validate(){
        return Type.Validate(this);
    }
}

public abstract class ContractType
{
    public int Id{ get; set; }
    public string Description{ get; set; }

    public abstract bool Validate(Contract contract);
}

public Class PreSale : ContractType
{
    public override bool Validate(Contract contract)
    {
        //here goes specific validation for PreSale
    }
}

public Class HighRiskSale : ContractType
{
    public override bool Validate(Contract contract)
    {
        //here goes specific validation for HighRiskSale
    }
}

public Class AprovedSale : ContractType
{
    public override bool Validate(Contract contract)
    {
        //here goes specific validation for AprovedSale
    }
}

我将使用Table Per Hierarchy方法来管理具体验证器

这是一种可恶的方法吗？

这样做有什么问题？

已更新

我被告知的主要论点是，我应该有一个简单的结构并从DI容器或服务定位器获取规则，但我不习惯在我的域模型上使用服务定位器。

提前致谢

Answer 1

我认为使用TPH方法没有任何问题，所以..为什么不呢？

它很简单，似乎与模型背后的语义相符。

我会考虑另一种方法，只有当你认为这些类将包含许多不会在它们之间共享的特定属性时，你认为它最终会在磁盘上占用大量空间，或者如果你不得不在这些字段上定义空约束。

Answer 2

我认为这里的主要问题是谁在维护规则。如果用户维护每个合同的合同和验证规则，那么您可能甚至没有ApprovedSales类，而是具有名称＆＃34; Approved Sale＆＃34;的contractType类的实例。如果你这样做，那么将验证规则存储在数据库中是很有意义的（如果你的验证规则变得复杂，那么将它们存储在数据库中也是如此）

如果合同类型是固定的，结合验证规则，那么只需将它们写为linq查询（或者你想编写验证）并对其进行硬编码。

如果你想存储验证器，你甚至可以考虑将它们存储为json对象。传统数据库工作不佳的原因是，如果我有2个验证，请说年龄＆gt; 18和Firstname至少4个字母，只有a-z然后我必须在数据库中存储非常不同的东西。如果我使用TPH方法，我可能有一个属性名（年龄，名字），数字（18,4）和allowedCharacters（a-z）字段。但是现在您已经看到，对于两种验证，数字字段的使用方式都有很大不同。所以我得到2个数字字段，其中1个总是空的......当然数据库可以处理这个但是json序列化甚至可以更快地到达那里（如果你想存储它）并且如果它没有改变对它们进行编码对于你的客户来说已经足够好了（即使从现在起2年后他想要改变合同，然后你花2个小时来改变你的代码，而不是花2小时来获得你的数据库结构设置）

保存数据库的验证规则

2 个答案: