Повторное использование объекта в другой сборке. Нужно помочь, зная, где искать / что узнать для ответа

1

Вероятно, проголосовали, но мне нужна моя проблема, поэтому я знаю, что/где искать ответ.

У меня есть "настройки" object1, определенные в сборке A. Объект - это свойства, но не такие, как B, C, D

У меня есть "настройки" object2, определенные в сборке B. Объект - это свойства, но не такие же, как A, C, D

У меня есть "настройки" object3, определенные в сборке C. Объект - это свойства, но не такие, как A, B, D

У меня есть "настройки" object4, определенные в сборке D. Объект - это свойства, но не такие, как A, B, C

и т.д....

Эти объекты "настроек" будут иметь одно общее свойство. Свойство Q.

Объект L будет ВСЕГДА быть установлен, но AD будет в разных комбинациях. Поэтому я в порядке с AD, имеющим ссылку на L, но я не хочу, чтобы L ссылался на AD.

У меня есть метод в сборке L, который потребляется A, B, C, D и т.д. Этот метод будет искать свойство Q в объекте настроек.

Я не хочу делать некоторые уродливые взлома тестирования /try/poking, пока не нахожу, какой объект установки сборки передается. Дальнейшая сборка E может быть добавлена, и я не хочу, чтобы НЕ перестраивать сборку L, чтобы добавить еще один "установочный" объект к взлому, чтобы его искать..

Кажется, я хочу использовать Generics и размышления, возможно, но просто не уверен, что это правильно?

Поэтому, чтобы немного приблизить ее, это пример объектов настроек:

//ASSEMBLY A
namespace User.Purchase.Product.A
{
    class SettingsA
   {
       public string Name{get;set;}
       public string Rank{get;set;}
       public string Serial{get;set;}
       public string Active{get;set;}
   }

   class DoWorkA
   {
      var PPP = new Object L; //psuedo code
      PPP.GetSettings(typeof(SettingsA));
   }

}


//ASSEMBLY B
namespace User.Purchase.Product.B
{
    class SettingsB
   {
       public string Branch{get;set;}
       public string MOS{get;set;}
       public string Promotion{get;set;}
       public string Active{get;set;}
   }

    class DoWorkB
   {
      var PPP = new Object L; //psuedo code
      PPP.GetSettings(typeof(SettingsB));
   }
}

//ASSEMBLY SettingsC
namespace User.Purchase.Product.C
{
    class C
   {
       public string Vehicle{get;set;}
       public string Engine{get;set;}
       public string FuelType{get;set;}
       public string Active{get;set;}
   }

   class DoWorkC
   {
      var PPP = new Object L; //psuedo code
      PPP.GetSettings(typeof(SettingsC));
   }
}

Общая сборка L

//ASSEMBLY L
namespace User.Common.Library
{
    class L
   {
      public bool GetSettings(Type type) //???? What / how to pass my generic object
      {
          ....somehow using reflection dynamically build my object definition for use
          by settings service below.

          var TTT = SomeManipulation(type); //obvious psuedo code here

          var xyz = settingService.LoadConfigObject<TTT>();

          if(xyz.Q)
          {...}

         //the settingService is already in existence and I would prefer to use it
         //instead of breaking DRY and creating an implementation just for this purpose.
      }
   }
}

Опять мои извинения за такой облачный вопрос.

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

Спасибо вам за терпение и помощь.

Теги:

2 ответа

3
Лучший ответ

Сделайте еще одну сборку и добавьте интерфейс к этой сборке, который определяет общие части между всеми этими объектами настроек.

то есть. как это:

public interface ICommonSettings
{
    string Q { get; set; }
}

Затем ссылайтесь на эту новую сборку из проектов AD и L и реализуйте этот интерфейс на этих 4 объектах настроек. Код в L, который будет использовать объекты настроек из AD, может искать этот интерфейс и определять, как объект настройки реализует общие части, но также использует "правильный путь" для доступа к этим свойствам.

Справа у вас это будет, где "A → B" означает, что A относится к B:

Изображение 174551

Вы также можете поместить интерфейс в сборку L, если L не требует ссылки на AD, таким образом вы уменьшите количество необходимых сборок. Однако лично я чувствую, что сборка только интерфейса - это лучший подход, поскольку вы извлекли биты, которые, как вы говорите, "DLL третьей части могут полагаться на эти биты".

  • 0
    Ооо, это отличная идея. Таким образом, я бы получил две сборки, которые являются обязательными для установки. Сборка L & Сборка Iface. Так есть ли название или концепция для этой ситуации, в которой мне нужно учиться?
  • 2
    @ user1278561 Термин для этого подхода - «Система плагинов». Есть примеры кода проектов на MSDN. В этой ссылке сборка PluginContracts представляет «сборку Iface» из вашего комментария, а FirstPlugin и SecondPlugin представляют ваши буквенные сборки.
2

В той же сборке, которая содержит класс L, создайте интерфейс настроек, который предоставляет свойство Q (IQProvider в моем примере)

public interface IQProvider
{
    string Q { get; set; }
}

class SettingsA : IQProvider
{
   public string Name{get;set;}
   public string Rank{get;set;}
   public string Serial{get;set;}
   public string Active{get;set;}
   public string Q { get; set; }
}

Тогда ваш метод GetSettings может принять это как параметр, больше не отражать!

class L
{
  public bool GetSettings(IQProvider qProvider)
  {
      return qProvider.Q.Equals("BLAH");
  }
}

Ещё вопросы

Сообщество Overcoder
Наверх
Меню