Является ли шаблон спецификации устаревшим, когда вы можете использовать Dynamic LINQ?

Question

Википедия утверждает, что шаблон спецификации — это то место, где бизнес-логику можно рекомбинировать путем объединения бизнес-логики вместе с использованием логической логики.Что касается выбора объектов фильтрации из списков или коллекций, мне кажется, что Dynamic LINQ позволяет мне сделать то же самое.Я что-то пропустил?Существуют ли другие преимущества шаблона спецификации, которые также следует учитывать?

---

Редактировать:

Я нашел несколько сообщений, в которых обсуждается объединение LINQ и шаблона спецификации:

Проект спецификаций Linq

Реализация шаблона спецификации через Linq, Николас Блюмхардт (чувак из Autofac)

Кто-нибудь проезжал по этой дороге и стало ли сложно ее поддерживать?

Answer 1

Dynamic LINQ использует строковые выражения, позволяющие создавать динамические запросы.Таким образом, мы фактически теряем здесь безопасность типов.В то время как использование шаблонов-оболочек, таких как шаблон декоратора его близкого воплощения, шаблон спецификации, позволяет нам поддерживать безопасность типов в коде.Я исследую использование шаблона Decorator в качестве оболочки запроса для повторного использования и динамического построения запросов.Вы можете найти статью о проекте кода по адресу:Оболочки запросов Linq

Или вы можете проверить мой блог.

Answer 2

Я разработчик C# и предпочитаю использовать шаблон спецификации, поскольку он ближе к моей сфере бизнеса.Более того, вас не удивит этот шаблон: если класс спецификации существует, он должен работать.В случае Linq ваш базовый провайдер, возможно, не реализовал некоторые функции, и вы не узнаете об этом до момента выполнения.

Но, безусловно, самое большое преимущество спецификации перед linq — это близость к бизнесу, это мини-DSL.Для меня LINQ — это DSL для сбора данных, а не для бизнес-сферы.

Answer 3

Я на самом деле не знаю LINQ, но мне кажется, что декларативная система запросов в целом связана с шаблоном спецификации.В частности, реализация декларативной системы запросов путем объединения объектов в объектно-ориентированной среде.IIRC это похоже на то, что делает LINQ, предоставляя слой синтаксического сахара.

Я не могу сказать, полностью ли LINQ устарел.Может быть, есть крайние случаи, которые просто невозможно выразить в LINQ?

Answer 4

ЛИНК:

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

Спецификация:

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

• Бизнес-логика — это инкапсулировано в спецификации (с именем, которое раскрывает, что это такое).
• СУХОЙ:вы не повторяете этот 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 тот ответственность решить, сможет ли он получить кредит?Банк спросит клиента, может ли он получить кредит?

Возможно нет.

Таким образом, со спецификацией вы можете удалить эту логику из Customer (он никогда ему не принадлежал).Вы можете создать что-то вроде IsAbleToReceiveCreditSpecification и поместите туда всю логику.Можно пойти дальше и объединить спецификации, например:вы могли бы создать SecureAgeSpecification и AssetsGreaterThanSpecification и использовать их для составления IsAbleToReceiveCreditSpecification.

Поэтому я не думаю, что LINQ заменяет Спецификацию.На самом деле это улучшает рисунок.Существуют некоторые реализации спецификации, которые используют LINQ внутри себя. IQueriable<T>, при этом вы можете использовать спецификацию внутри своих запросов ORM на уровне репозитория/доступа к данным.