Выбор дизайна для интеграции обработки лицензий

Question

Для нашего приложения .Net мы интегрировали компонент лицензирования в приложение.В коде приложения мы проверяем лицензию и на ее основе нам необходимо включить / отключить некоторые функции.Например, если у пользователя есть пробная лицензия, он может получить доступ только к определенным разделам приложения, тогда как платный пользователь может получить доступ к любой части.Мне нужна помощь в выборе дизайна, чтобы воздействие было минимальным.Я не хочу посыпать код заявлениями if..else.Пожалуйста, поделитесь со мной некоторыми оптимальными способами добиться этого.

Answer 1

Как всегда, ответом является заменить условный полиморфизм .

Инкапсулировать каждую функцию как Стратегия и реализовать отключенную функцию как Нулевой объект .Затем оба могут быть инкапсулированы в условную Composite , которая выбирает между двумя на основе компонента лицензирования.

В качестве примера представьте, что у вас есть функция печати, инкапсулированная за интерфейсом IPrinter,Вы реализуете реальную функцию в классе RealPrinter и функцию отключения в классе NullPrinter, оба реализуют интерфейс IPrinter.

Проверка лицензии может быть реализована в классе GuardedPrinter, который будет выглядетькак то так:

public class GuardedPrinter : IPrinter
{
    private readonly IPrinter realPrinter;
    private readonly IPrinter nullPrinter;
    // more fields and initialization omitted for brevety...

    public PrintResult Print()
    {
        if (this.licence.IsEnabled)
        {
            return this.realPrinter.Print();
        }

        return this.nullPrinter.Print();
    }
}

Answer 2

Вам не нравятся операторы If / Else для проверки включенных функций или специфический опрос системы лицензий среди логики вашей основной программы?

Я не вижу, как вы можете отключить функциональность без операторов If / Else, но вы можете поддерживать ее в чистоте, если у вас есть класс License, который обо всем позаботится.

У меня будет класс лицензии, который инициализируется при запуске приложения и имеет метод public bool IsFeatureLicensed(string MethodName).

Каждый метод, предоставляющий функцию, которую вы хотите защитить с помощью лицензии, будет иметь что-то вроде:

If (LicenceManager.IsFeatureLicensed(Reflection.MethodBase.GetCurrentMethod.Name)) {

  //Do your stuff!

} else {
  //Throw exception or show error message or something.
}

Метод IsFeatureLicensed в создаваемом вами классе LicenseManager взглянет на имя метода и проверит, позволяет ли лицензия использовать функцию, предоставляемую этим методом. Он должен возвращать True во всех случаях, кроме случаев, когда лицензия запрещает использование этой функции.

Таким образом, каждый метод выполняет идентичный вызов менеджера лицензий (что делает его очень простым в обслуживании), и все, что связано с лицензированием, заключено в один класс. Это позволяет вам очень легко изменить способ лицензирования (например, вы можете просто вернуть True для всего во время разработки), и к остальной части вашего приложения не нужно прикасаться.

Answer 3

Можно запланировать наличие нескольких «лицензионных продуктов», каждый из которых имеет свой собственный набор уникальных лицензионных ключей.Продукт A может разблокировать Функцию 1,2 и 3, в то время как Продукт B может разблокировать только Функцию 1. В вашем конструкторе, для которого создается экземпляр Функции 1, вы можете проверить наличие определенного кода лицензии, чтобы проверить, является ли этот лицензионный ключ действительным для Продукта AИЛИ Продукт B. Вы можете сделать то же самое для Функции 2 и 3, которая проверяет только лицензионный ключ, который относится к Продукту B.

Проверка должна выполняться статически, чтобы, если проверка прошла первый раз, то когдаВы никогда не должны проверять проверку еще раз, если создан экземпляр функции А.Статический класс диспетчера лицензирования, вероятно, может справиться с этим.

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

Answer 4

может быть, вы могли бы использовать технику .NET licx, описанную здесь?

Модель лицензирования .NET на основе Licx