Статический репозиторий ... не может использовать DI, что делать?

Question

Я нахожусь в ситуации, когда нам нужно изменить то, что возвращается из статического репозитория в стороннем приложении с открытым исходным кодом (NopCommerce).Проблема в том, что они используют статические репозитории, поэтому я не могу просто наследовать интерфейс и DI свой собственный репозиторий.Я пытаюсь сделать это без изменения кодовой базы NopCommerce ... какие-нибудь свежие идеи?

Редактировать: Я хочу, чтобы NopCommerce использовала мои репо, а не мой код использовал их.

Answer 1

В настоящее время у нас очень, очень сжатые сроки, и эта проблема не была предвидена.Поэтому я подумываю сначала начать со статического интерфейса бедного человека / DI бедного человека, как показано ниже (поэтому мне не нужно изменять все решение).Затем в более позднее время, когда у нас не так уж мало времени, перейдите на использование интерфейса и внедрения зависимостей и отправьте исправление в NopCommerce:

// Poor-man's static interface (DI).
public static class OriginalBuiltInStaticClass {
    private static IMyNewClass _myNewClass;

    public static void Inject(IMyNewClass myNewClass) {
        _myNewClass = myNewClass;
        A = _myNewClass.A;
        B = _myNewClass.B;
        C = _myNewClass.C;
    }

    public static Action A = CopySimpleRenameBuiltInStaticClass.A;
    public static Func<int, string> B = CopySimpleRenameBuiltInStaticClass.B;
    public static Action C = CopySimpleRenameBuiltInStaticClass.C;
}

// Original vendor class which was copied and renamed.
public static class CopySimpleRenameBuiltInStaticClass {
    public static void A() {
        Console.WriteLine("OriginalBuiltInStaticClass.A()");
    }

    public static string B(int id) {
        Console.WriteLine("OriginalBuiltInStaticClass.B()");
        return id.ToString();
    }

    public static void C() {
        Console.WriteLine("OriginalBuiltInStaticClass.C()");
    }
}

// Creating an interface to merge into trunk of NopCommerce (convert static repositories)
public interface IMyNewClass {
    void A();
    string B(int id);
    void C();
}

// Implementation of interface.
public class MyNewClass : IMyNewClass {
    public void A() {
        Console.WriteLine("MyNewClass.A()");
    }

    public string B(int id) {
        Console.WriteLine("MyNewClass.B()");
        return id.ToString();
    }

    public void C() {
        CopySimpleRenameBuiltInStaticClass.C();
    }

}

Есть мысли?

Answer 2

Вы можете абстрагироваться от их вещей, создав собственный интерфейс и реализацию класса, делегирующую NopCommerce.Затем пусть ваш код использует интерфейс вместо прямого доступа к классам NopCommerce.Вы можете изменить вывод NopCommerce внутри своего класса до того, как результат будет возвращен вашему приложению.

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

Примерно так, в коде:

public interface IRepository 
{
   MyItem GetItem(int id);
}

public class MyNopCommerceWrapper : IRepository
{
   public MyItem GetItem(int id)
   {
       // I have no idea what NopCommerce API looks like, so I made this up.
       var myItem = NopCommerce.GetItem(id);

       ModifyMyItem(myItem);

       return myItem;
   }
}

Answer 3

Звучит как работа для Фасад .