Двойная проверка - имеет ли смысл иметь внутренний класс viewmodel?

Question

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

Поэтому я думаю, что все связанные с привязкой реализации IValueConverter, IMultiValueConverter, INotifyPropertyChanged, INotifyCollectionChanged должны всегда быть открытыми для работы с XAML.

Это правильно?

ОБНОВЛЕНИЕ: это не такой простой вопрос, потому что существуют различные возможные странные случаи, такие как вложенные классы модели представления, или явные реализации интерфейса или что-то еще, о чем я не знаю, что могло бы привести к разные ответы. Как мы уже видим, WPF и SL4.0 почему-то по-разному относятся к внутренним моделям представления.

Answer 1

Сделал некоторую проверку, основываясь на этом коде:

<UserControl>
    <UserControl.Resources>
        <sa1:TestValueConverter x:Key="TestValueConverter" />
    </UserControl.Resources>

    <Grid x:Name="LayoutRoot" Background="White">
        <TextBlock Text="{Binding Data, Converter={StaticResource TestValueConverter}}" />
    </Grid>
</UserControl>

public class TestViewModel : INotifyPropertyChanged
{
    public string Data { get; set; }
    public event PropertyChangedEventHandler PropertyChanged;
}

public class TestValueConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        return "-" + value.ToString() + "-";
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

Интересно, что результаты отличаются для WPF и Silverlight.

И ответы:

В Silverlight:

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

2. "реализации IValueConverter, IMultiValueConverter" - да, также должен быть публичным

3. "INotifyPropertyChanged, INotifyCollectionChanged"- эти интерфейсы реализуются классами ViewModel и некоторой коллекцией, которая будет связана, поэтому эти классы должны быть общедоступными, как мы уже знаем.И методы и события, которые реализуют интерфейсы, очевидно, не могут быть частными или внутренними.

В WPF:

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

2. » реализации IValueConverter, IMultiValueConverter »- can быть внутренним

3. "INotifyPropertyChanged, INotifyCollectionChanged" - см. Предыдущие пункты.

Answer 2

Причина, по которой две среды (Silverlight и WPF) ведут себя по-разному, заключается в ограничениях отражения Silverlight.

В Silverlight нельзя использовать отражение на внутренних или закрытых элементах .

Таким образом, если модель представления объявлена ​​как внутренняя, silverlight не сможет использовать ее для привязки данных.

Answer 3

Невозможно привязать внутренние свойства, но не имеет значения, насколько доступен исходный объект (например, DataContext), пока свойства являются общедоступными.

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