问题标签 [specification-pattern]

我正在构建一个表单管理系统，也就是说，系统将包含许多表单，将保存它们，并对它们执行逻辑，我想使用 DDD 方法来实现。

我想在以后使用 ASP.NET MVC 支持简单的表单布局，到目前为止，我看到的域是这样的：

我将有一个基本表单实体，它应该（现在）有一个名称、字段（和它们的值）和验证逻辑。

我的问题是：

1. 我应该如何使用泛型编写字段值对象？我似乎无法弄清楚..
2. 我应该将验证逻辑封装在表单中还是使用规范模式来完成？

与任何设计模式一样，规范模式是一个很棒的概念，但容易被急切的架构师/开发人员过度使用。

我即将开始开发一个新的应用程序（.NET 和 C#），并且非常喜欢规范模式的概念，并渴望充分利用它。然而，在我全力以赴之前，我真的很想知道是否有人可以分享在开发应用程序时使用规范模式时遇到的痛点。

理想情况下，我想看看其他人是否有问题

• 根据规范模式编写单元测试
• 确定规范应位于哪一层（存储库、服务、域等）
• 当一个简单的if语句可以完成工作时，在任何地方都使用它
• ETC？

提前致谢

我正在实施规范模式。NotSpecification 起初看起来很简单：

但它不适用于所有规格：

这应该返回 false 而不是 true。到目前为止，我认为完成 NotSpecification 的 isSpecialCaseOf 的唯一方法是实现其余的UnsatisfiedBy（在规范模式的论文中部分包含）。但也许我错过了一些更简单或合乎逻辑的洞察力，这使得这变得不必要。

问题：是否有另一种不使用remainderUnsatisfiedBy 来实现这一点的方法？

在我们的项目中，我们使用布尔运算符实现了规范模式（参见 DDD p 274），如下所示：

这允许使用方法链很好地表达规则，但它不支持可能导致细微错误的标准运算符优先规则。

以下规则不等效：

如果汽车不是敞篷车，则不满足规则isNiceCar2 ，这可能会令人困惑，因为如果它们是布尔值

我意识到如果我们将 isNiceCar2 重写为 isFerrari.or(isRed.and(isConvertible))，它们将是等价的，但两者在语法上都是正确的。

我们能想到的最佳解决方案是取缔方法链，并改用构造函数：

有人有更好的建议吗？

我创建了一个工厂和一组规范来创建和验证聚合根。目前我对工厂进行了一些测试，调用工厂产品的规格，但我想知道这是否足够。从设计的角度来看，将工厂与其产品的规格结合起来可能会更好，因为它们是密切相关的。

如果聚合根产品的规范用于验证而不是创建，那么从工厂内部调用它是否有意义？

还是单元测试足够好？

我有一个 Func 定义如下：

我可以像这样查询 IEnumerables：

但是当我尝试为 IQueryable 的 Where 方法提供相同的 Func 时，我得到：

'无法将源类型 System.Collections.Generic.IEnumerable 转换为 System.Linq.IQueryable。'

这是怎么回事？我如何定义一个可以同时作为 IEnumerable 和 IQueryable 规范的 Func？

如果我有一个定义为如下表达式的规范：

我想用逻辑“超人且是女性”定义另一个规范“IsSuperheroine”，如何在新规范中重用现有规范？

我正在做一些研发工作，因此正在探索设计模式。我最近一直在阅读规范模式，并提到了这篇很棒的文章。

我对代码的简洁性和简洁性很感兴趣，但我开始对使用其他技术实现相同的简洁性进行一些比较。

考虑以下服务层的接口契约：

所以，一些初始点：

• 所有三个都返回 Foo 对象的集合
• 三者都接受一个论点
• 规范方法限制对特定要求的访问
• 谓词方法基本没有限制
• 搜索 args 方法限制对特定要求的访问

现在，进入实现：

实施要点：

• 这三个在实现上都非常简单（一行链式代码）
• 规范和搜索参数过滤在外部实现。
• 搜索 args 方法只是使用 IEnumerable 扩展方法来检查 args

那么，话虽如此，在什么条件下您会使用上述三种技术中的一种？

我对规范模式的看法：

• 很好，因为它将业务/域需求隔离到可重用的组件中
• 非常容易阅读，让代码说英语
• 涉及相当多的代码（接口、抽象类）。如果我要使用它，我会将抽象放在一个通用程序集中（所以我的解决方案中没有一堆静态文件）。
• 只需更改规范而不是服务层即可轻松更改需求。
• 领域逻辑的最高可测试性（规范）

我对扩展方法（管道和过滤器）的看法：

• 逻辑上的“重量级”，但仍然具有相同的简单性。
• 将查询逻辑从服务层隔离到静态方法
• 仍然需要排序的“反射”（检查提供的搜索参数并建立查询）
• 允许您首先对架构（存储库、服务层）进行编码，而无需考虑特定的业务需求（在某些场景中很方便）

我对谓词方法的看法：

• 可用于您需要对查询进行粗粒度控制的地方。
• 适用于规格可能过度的小型项目

我最终的思考逻辑是，如果您正在处理一个复杂的业务应用程序，其中业务需求是预先知道的，但可能会随着时间的推移而改变，那么我会使用规范模式。

但是对于一个“启动”的应用程序，即需求会随着时间的推移而发展，并且有多种方法可以在没有复杂验证的情况下检索数据，我会使用 Pipes 和 Filters 方法。

你怎么认为？你们中的任何人在使用上述任何方法时遇到过问题吗？有什么建议吗？

即将开始一个新项目，因此这些类型的考虑因素至关重要。

谢谢您的帮助。

编辑以澄清规范模式

这是规范模式的相同用法。

我正在使用规范模式，并且有一个工作实现（取自 WhoCanHelpMe Codeplex 项目），用于通过 NLinq、通用存储库和所有这些优点获取数据。

根方法是：

FindAll() 方法执行以下操作：

而且，SatisfyingElementsFrom() 这样做：

因此，对于通过 Case 的 CaseNb 属性查询案例，这非常简单。像下面这样的规范对我有用，并得到我想要的案例。

但是，我不知道在跨越多个实体时如何做到这一点。我想要的是一个允许我按用户名获取案例的规范。基本上，在数据库中，有三个表，这些表已经被携带到实体中。以下是实体：

这是案例类：

这是案例用户：

并且，用户：

我将如何编写表达式以跨关联表获取数据？

我放弃了这段代码，因为它有效，但我真的需要重构一些可以接受的东西。它接受一组查询对象（看起来像 productid = 3 的字符串），然后将它们添加到我的查询中。这仅适用于逻辑 AND，但我最终将需要一些不同的逻辑运算符（OR、NOT）。

我也有这个订购：

那么，我如何将每个重复封装到一个规范对象中，以便以某种方式将这个规范集合附加到我的原始查询中，包括订单表达式？这是在 Linq to Entities、Entity Framework 4 和 C# 保护伞下。

做这样的事情真的很好，这基本上就是上面所做的。

网站链接，示例代码，肯定会受到赞赏。