当前位置：文江博客话题详情

当您可以使用动态 LINQ 时，规范模式是否已过时？

发布于 2024-08-05 05:53:44 字数 583 浏览 13 评论 0原文

Wikipedia 指出规范模式是可以通过使用布尔值将业务逻辑链接在一起来重新组合业务逻辑的地方逻辑。关于从列表或集合中选择过滤对象，在我看来，动态 LINQ 允许我完成同样的事情。我错过了什么吗？规范模式是否还有其他值得考虑的好处？

编辑：

我发现了一些讨论结合 LINQ 和规范模式的帖子：

Linq 规范项目

通过 Linq 实现规范模式，作者：Nicloas Blumhardt（Autofac 兄弟） )

有没有人走过这条路，维护起来是否变得复杂？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

你另情深 2024-08-12 05:53:44

我是一名 C# 开发人员，喜欢使用规范模式，因为它更接近我的业务领域。此外，您对这种模式不会有任何惊讶，如果存在规范类，它应该可以工作。使用 Linq，您的底层提供程序可能尚未实现某些功能，并且直到运行时您才会知道。

但肯定的是，规范相对于linq的最大优势是更贴近业务，它是一个迷你DSL。 LINQ对我来说是一个用于集合查询的DSL，而不是用于业务领域的。

回复收藏 0 原文

以酷 2024-08-12 05:53:44

LINQ：

var oldMans = Persons.Where(x => x.Sex == SexEnum.Masculine && x.Age > 60).ToList();

规范：

var oldMans = Persons.Where(x => IsOldManSpecification(x)).ToList();

业务逻辑封装在规范中（其名称可以揭示其内容）。
DRY：您不必在代码上重复该 linq，只需使用规范

当我认为规则足够重要，需要在代码中明确显示并且它自然不属于实体时，我喜欢使用规范。

示例：

public class Customer
{
    //...

    public bool IsAbleToReceiveCredit(decimal creditValue)
    {
        var secureAge = this.Age > 18 && this.Age < 60;
        var personalAssetsGreaterThanCreditValue = this.PersonalAssets.Sum(x => x.Value) > creditValue;

        return secureAge && personalAssetsGreaterThanCreditValue;
    }
}

客户是否有责任来决定他是否能够获得一些信用？银行会询问客户是否可以获得贷款？

可能不会。

因此，通过规范，您可以从 Customer 中删除该逻辑（它从未属于它）。您可以创建类似 IsAbleToReceiveCreditSpecification 的内容，并将所有逻辑放在那里。我们可以进一步组合规范，例如：您可以创建一个 SecureAgeSpecification 和一个 AssetsGreaterThanSpecification 并使用它们来组成 IsAbleToReceiveCreditSpecification。

所以我不认为 LINQ 会取代规范。事实上，它改进了模式。有一些规范的实现在内部使用 LINQ 和 IQueriable，这样您就可以在 Repository/DataAcess 级别的 ORM 查询中使用该规范。

LINQ:

var oldMans = Persons.Where(x => x.Sex == SexEnum.Masculine && x.Age > 60).ToList();

Specification:

var oldMans = Persons.Where(x => IsOldManSpecification(x)).ToList();

The business logic is encapsuled in the specification (with a name that reveal what it is).
DRY: you don't repeat that linq over the code, you just use the Specification

I like to use specification when I think that the rule is important enough to be explicit in the code and it doesn't belongs naturally to the entity.

Example:

public class Customer
{
    //...

    public bool IsAbleToReceiveCredit(decimal creditValue)
    {
        var secureAge = this.Age > 18 && this.Age < 60;
        var personalAssetsGreaterThanCreditValue = this.PersonalAssets.Sum(x => x.Value) > creditValue;

        return secureAge && personalAssetsGreaterThanCreditValue;
    }
}

Is it from the Customer the responsability to decide if he is able to receive some credit? A bank would ask to the customer if he can receive a loan?

Probably not.

So with specification you can remove that logic from the Customer (it never belonged to it). You can create something like IsAbleToReceiveCreditSpecification and put all logic there. We can go further and combine specifications, for example: you could create a SecureAgeSpecification and a AssetsGreaterThanSpecification and use them to compose the IsAbleToReceiveCreditSpecification.

So I don't think LINQ replaces the Specification. In fact it improves the pattern. There are some implementations of Specification that use LINQ internally with IQueriable<T>, with this you can use the specification inside your ORM queries on the Repository/DataAcess level.

回复收藏 0 原文