Подтвердить что ты не робот

Готова ли ReactiveUI?

Я изучил возможность использования Reactive UI в производственном коде. Некоторые из функций действительно привлекательны, но я беспокоюсь о зависимости от этой библиотеки. К ним относятся:

  • Безусловное название и условные обозначения. Например, защищенные члены, начиная с нижнего регистра, и метод RaiseAndSetIfChanged зависят от вашего личного члена, начинающегося с символа подчеркивания. Я понимаю, что Пол Беттс (автор ReactiveUI) имеет фон Ruby, поэтому я предполагаю, что там, где возникает нечетное название. Однако это вызовет для меня настоящую проблему, поскольку стандартное присвоение имен (в соответствии со стилем) применяется во всем моем проекте. Даже если бы это не было соблюдено, я был бы обеспокоен возникающей несогласованностью в названии, что это вызовет.
  • Отсутствие документации/образцов. Существует некоторая документация и одинокий образец. Тем не менее, документация представляет собой всего лишь несколько (старых) сообщений в блогах, а образец основан на V2 библиотеки (теперь он на V4).

  • Нечетная конструкция, по частям. Например, ведение журнала абстрагируется, чтобы не зависеть от конкретной структуры ведения журнала. Справедливо. Однако, поскольку я использую log4net (а не NLog), мне нужен мой собственный адаптер. Я думаю, что это потребует от меня реализовать IRxUIFullLogger, в котором есть метрическая зависимость от методов (более 50). Я бы подумал, что гораздо лучший подход состоит в том, чтобы определить очень простой интерфейс, а затем предоставить методы расширения в ReactiveUI для облегчения всех необходимых перегрузок. Кроме того, существует такой странный IWantsToRegisterStuff интерфейс, от которого зависит сборка NLog, от которой я не буду зависеть (потому что это внутренний интерфейс). Я надеюсь, что мне это не понадобится...

    В любом случае, моя забота здесь об общем дизайне библиотеки. Кто-нибудь был укушен этим?

  • Я уже широко использую MVVM Light. Я знаю, что Пол сделал сообщение в блоге, где он объясняет, что вы можете технически использовать и то, и другое, но моя озабоченность связана с ремонтопригодностью. Я подозреваю, что это было бы ужасно запутанным, если бы оба смешались в одной кодовой базе.

Есть ли у кого-нибудь практический опыт использования Reactive UI в производстве? Если да, можете ли вы смягчить или решить любую из моих проблем?

4b9b3361

ОТВЕТЫ

Ответ 1

Пройдите через свои проблемы по частям:

# 1. "Безумные имена и условные обозначения".

Теперь, когда ReactiveUI 4.1+ имеет имя CallerMemberName, вам вообще не нужно использовать соглашения (и даже тогда вы можете переопределить их через RxApp.GetFieldNameForPropertyFunc). Просто напишите свойство как:

int iCanNameThisWhateverIWant;
public int SomeProperty {
    get { return iCanNameThisWhateverIWant; }
    set { this.RaiseAndSetIfChanged(ref iCanNameThisWhateverIWant, value); }
}

# 2. Отсутствие документации/образцов

Это законно, но здесь еще несколько docs/samples:

# 3. "Я бы подумал, что гораздо лучший подход состоял бы в том, чтобы определить очень простой интерфейс, а затем предоставить методы расширения в ReactiveUI для облегчения всех необходимых перегрузок"

Внесите IRxUILogger вместо этого, у него есть несколько методов: ReactiveUI заполнит остальные. IRxUIFullLogger только там, если вам это нужно.

"Кроме того, есть этот странный интерфейс IWantsToRegisterStuff"

Вам не нужно знать об этом:) Это касается только инициализации ReactiveUI, поэтому вам не нужно иметь шаблонный код.

  1. "Я подозреваю, что это было бы ужасно запутанным, если бы оба смешались в одной кодовой базе".

Не совсем. Подумайте об этом как "MVVM Light с SuperPowers".

Ответ 2

Я отвечаю, как тот, кто использовал ReactiveUI в нескольких производственных системах, имел проблемы с тем, как RxUI действительно работает, и отправил исправления, чтобы попытаться исправить проблемы, которые у меня были.

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

  • Нейминг. Я думал, что это тоже странно. Это оказалось одной из функций, которые я действительно не использую. Я использую PropertyChanged.Fody для сплетения в уведомлении об изменении с помощью АОП. В результате мои свойства выглядят как автоматические свойства.

  • Doco. Да, может быть и больше. Особенно с новыми деталями, такими как маршрутизация. Возможно, это причина, по которой я не использую все RxUI.

  • Logging

    . У меня были проблемы с этим в прошлом. См. запрос на извлечение 69. В конце дня я вижу RxUI как очень упрямую структуру. Если вы не согласны с этим мнением, вы можете предложить изменения, но все. Мнение не делает это плохо.

  • Я использую RxUI с Caliburn Micro. CM обрабатывает местоположение и привязку View-ViewModel, экран и проводники. Я не использую привязку условных обозначений. RxUI обрабатывает команды и код ViewModel INPC и позволяет мне реагировать на изменения свойств с помощью Reactive вместо традиционных подходов. Сохраняя эти вещи отдельно, мне намного легче смешивать их.

Есть ли какие-либо из этих проблем, связанных с готовностью производства? Неа. ReactiveUI стабилен, имеет приличную размерную базу пользователей, проблемы быстро решаются в группе google, и Пол восприимчив к обсуждению.

Ответ 3

Я использую его в производстве, и до сих пор RxUI был абсолютно стабильным. У приложения были проблемы со стабильностью, некоторые - с EMS, другие - с обработчиком UnhandledException, который вызывал больше проблем, чем он решал, но у меня не было никаких проблем с частью приложения ReactiveUI. Тем не менее, у меня были проблемы с ObservableForProperty, которые вообще не срабатывали, и я, возможно, неправильно использовал их и работал последовательно (неправильно) в своем тестовом коде, а также в интерфейсе пользователя во время выполнения.

-1. Пол объясняет, что _Upper должен использовать рефлексию, чтобы попасть на частное поле в вашем классе. Вы можете использовать блок, такой как ниже, для работы с сообщениями StyleCop и Resharper, которые легко сгенерировать (из Resharper SmartTag)

    /// <summary>The xxx view model.</summary>
    public class XXXViewModel : ReactiveObject
    {
    #pragma warning disable 0649
    // ReSharper disable InconsistentNaming

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private readonly bool _IsRunning;

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private string _Name;
    ....

или изменить свои свойства из полного

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _IsSelected; }
        set { this.RaiseAndSetIfChanged(x => x.IsSelected, value); }
    }

к его составным частям, таким как

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _isSelected; }
        set 
        { 
            if (_isSelected != value)
            {
                this.RaisePropertyChanging(x => x.IsSelected); 
                _isSelected = value;
                this.RaisPropertyChanged(x=>x.IsSelected);
            }
        }
    }

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

-2. Да, документация не идеальна, но я обнаружил, что после Rx выбор образцов RxUI был довольно прост. Я также отмечаю, что скачки от 2- > 4, похоже, все пришли к изменениям в поддержке Windows 8/Windows 8 Phone, и, получив ReactiveUI для приложения Windows Store, поддержка DotNet 4.5 отличная. то есть использование [CallerName] теперь означает, что вы просто это. RaiseAndSetIFChanged (значение) не нуждается в выражении.

-3. У меня нет обратной связи на стороне регистрации, поскольку я не решил использовать ее.

-4. Я не смешивал и не сопоставлялся с другими структурами.

Также есть список других участников ReactiveUI 4.2 на http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/, включая Phil Haack.