C # Объект редактирования и инициализации с сериализацией

Question

У меня проблемы с разделением значений свойств и их методов доступа.У меня есть некоторые электронные инструменты, заключенные в классы.Некоторые обертывают DLL, предоставленную производителем для обработки сообщений.

Простой пример:

public class Instrument
{
    private ManufacturerDLL.Instrument _instrument;

    public Instrument()
    {
        _instrument = new ManufacturerDLL.Instrument;
    }
    public float SomeSetting
    {
        get
        {
            return _instrument.SomeSetting;       
        }
        set
        {
            _instrument.SomeSetting = value;
        }
    }
}

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

Есть ли простой способ создать «абстрактную» версию объекта?Я в основном хочу клон, но заменил оригинальную логику методов доступа частными полями.Я знаю, что могу использовать GetMembers, но куда идти?

Answer 1

У вас есть несколько возможностей, поэтому вам придется выбирать в зависимости от конкретной ситуации, которая кажется наиболее вероятной.

Отдельно : Как и в ответе Марка Гравелла, вы можете отделить свою модельполностью от производителя и использовать внешний анализатор, который обрабатывает желаемые транзакции, выполняя определенные вызовы.Я бы использовал этот подход, только если вы не можете представить себе слой абстракции для работы поверх оригинальных библиотек DLL.

Decorator : поскольку вы хотите добавить поведение в данную библиотеку (проверьте соединение), первое, что приходит на ум, - это использование шаблона декоратора .Это в основном сводится к тому, что вы намекали в первую очередь;оборачивая всю DLL и реализуя дополнительную промежуточную логику, где это необходимо.Поскольку вы пишете декоратор вручную, существует множество изменений API, которые вы можете сделать, чтобы удовлетворить его вашим потребностям.

Proxy : в зависимости от того, насколько разнообразна эта промежуточная логика, которую вы хотите реализоватьможно использовать шаблон прокси .Например, когда все, что вы хотите сделать, это раскрыть исходные свойства и добавить одинаковое дополнительное поведение для каждого свойства.Когда классы Instrument производителя реализуют интерфейсы, вы можете сгенерировать класс, который реализует этот интерфейс во время выполнения и перенаправляет вызовы фактической DLL производителя.Это не легко, но есть несколько библиотек, которые могут помочь вам сделать это. Castle DynamicProxy или более низкого уровня RunSharp .Подумайте только о том, чтобы идти по этому пути, когда сможете воспользоваться его преимуществами.Например, когда вы должны обернуть большую библиотеку или библиотеку, которая часто меняется со временем.

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

Я могу привести пример сгенерированного времени выполненияproxy , созданный с помощью RunSharp, просто чтобы дать вам представление о том, что вы хотели бы попробовать.Функция CreateGenericInterfaceWrapper<T>() оборачивает любой интерфейс «менее универсальным» интерфейсом , генерируя при необходимости приведения.

Answer 2

Если бы это был я, я бы разделил 2 вещи, а именно: мое представление данных (использованное для сериализации и большинства манипуляций) и b: представление производителей. Вы в значительной степени вынуждены следовать по этому маршруту вашими требованиями. Затем я бы добавил, например, метод ApplyTo(Instrument), который применял значения на основе имени к имени, возможно, с использованием сериализации. Я думаю, это избавит вас от боли, особенно если вы сократите свои свойства до:

public float SomeSetting {get;set;}

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