Вероятно, проголосовали, но мне нужна моя проблема, поэтому я знаю, что/где искать ответ.
У меня есть "настройки" 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.
}
}
}
Опять мои извинения за такой облачный вопрос.
Я просто ищу какое-то направление в том, что мне нужно, чтобы научиться осмысливать эту ситуацию.... или, возможно, мне нужно изменить мою архитектуру, потому что я нарисовал себя в углу и т.д.
Спасибо вам за терпение и помощь.
Сделайте еще одну сборку и добавьте интерфейс к этой сборке, который определяет общие части между всеми этими объектами настроек.
то есть. как это:
public interface ICommonSettings
{
string Q { get; set; }
}
Затем ссылайтесь на эту новую сборку из проектов AD и L и реализуйте этот интерфейс на этих 4 объектах настроек. Код в L, который будет использовать объекты настроек из AD, может искать этот интерфейс и определять, как объект настройки реализует общие части, но также использует "правильный путь" для доступа к этим свойствам.
Справа у вас это будет, где "A → B" означает, что A относится к B:
Вы также можете поместить интерфейс в сборку L, если L не требует ссылки на AD, таким образом вы уменьшите количество необходимых сборок. Однако лично я чувствую, что сборка только интерфейса - это лучший подход, поскольку вы извлекли биты, которые, как вы говорите, "DLL третьей части могут полагаться на эти биты".
В той же сборке, которая содержит класс 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");
}
}
PluginContracts
представляет «сборку Iface» из вашего комментария, аFirstPlugin
иSecondPlugin
представляют ваши буквенные сборки.