event - wpf inotifypropertychanged

Cuándo usar una Propiedad de Dependencia de WPF versus INotifyPropertyChanged

Question

¿Las personas tienen alguna guía sobre cuándo una propiedad .NET simple que dispara INotifyPropertyChanged.PropertyChanged es suficiente en un modelo de vista? Entonces, ¿cuándo quieres pasar a una propiedad de dependencia completa? ¿O los DP están destinados principalmente para vistas?

Answer 1

Como las otras respuestas ya han dicho suficiente sobre cuándo crear propiedad de dependencia. es decir

1. Heredación PropertyValue
2. necesitas usar enlace en una propiedad
3. Use animación para la propiedad

La perspectiva / pregunta más sobre esto es "En una aplicación WPF tiene sentido crear propiedades de dependencia en una causa de control que es probable que cambien durante la interacción del usuario como altura, ancho, texto, contenido, fondo, etc. pero ¿qué pasa con otras clases como Clases de comportamiento (clases no UI). ¿Las propiedades en esas clases deben ser propiedad de dependencia?

No voy a decir por absoluto o enfatizar algunas reglas aquí, pero debes crear tus propiedades como DP. Desde la perspectiva del diseño, si una propiedad es DP siempre está en forma predeterminada de WPF para usar / bind.ie

1. Como DP es mucho más rápido / natural en reflejar los cambios en comparación con una propiedad CLR normal.
2. Un DP tiene un mecanismo de validación para validar el valor asignado y una estructura predeterminada para revertir el valor.
3. Un DP tiene una devolución de llamada de valor Coerce para controlar los límites de la propiedad.
4. Un DP tiene metadatos asociados a él a diferencia de la propiedad CLR.

En términos de prácticas, he visto personas que cometen muchos errores en las vinculaciones anidadas y luego plantean cambios. Este tipo de fallas no ocurren con una causa de DP debido a su diseño y la compatibilidad de generar cambios en sí. Entonces, con un poco de sintaxis adicional, le otorga flexibilidad / rendimiento / facilidad a su aplicación. Así que ve por ello siempre que sea asequible.

Todavía no puedo decir seguro para las clases de ViewModel / otras clases de ayuda. actualizará la respuesta si encuentra razones convincentes en el futuro.

Solo una publicación que vale la pena leer sobre este tema

Answer 2

El problema principal que veo con INotifyPropertyChanged es que si el modelo de vista es complejo y contiene muchos tipos anidados, parece que tiene que pasar el evento PropertyChanged a través de la jerarquía.

Answer 3

Hay algunos enfoques:

1. La propiedad de dependencia

Mientras usa la propiedad de dependencia, tiene más sentido en elementos: clases que tienen una apariencia visual ( UIElement s).

Pros:

• WPF hace las cosas lógicas por ti
• Algunos mecanismos como la animación usan solo propiedad de dependencia
• ''Se adapta'' al estilo de ViewModel

Contras:

• Necesita derivar formulario DependencyObject
• Un poco incómodo para cosas simples

Muestra:

public static class StoryBoardHelper
{
    public static DependencyObject GetTarget(Timeline timeline)
    {
        if (timeline == null)
            throw new ArgumentNullException("timeline");

        return timeline.GetValue(TargetProperty) as DependencyObject;
    }

    public static void SetTarget(Timeline timeline, DependencyObject value)
    {
        if (timeline == null)
            throw new ArgumentNullException("timeline");

        timeline.SetValue(TargetProperty, value);
    }

    public static readonly DependencyProperty TargetProperty =
            DependencyProperty.RegisterAttached(
                    "Target",
                    typeof(DependencyObject),
                    typeof(Timeline),
                    new PropertyMetadata(null, OnTargetPropertyChanged));

    private static void OnTargetPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        Storyboard.SetTarget(d as Timeline, e.NewValue as DependencyObject);
    }
}

2. The System.ComponentModel.INotifyPropertyChanged

Por lo general, al crear un objeto de datos, usará este enfoque. Es una solución simple y ordenada para cosas parecidas a datos.

Pros y contras: complementario a 1. Necesita implementar solo un evento (PropertyChanged).

Muestra:

public class Student : INotifyPropertyChanged 
{ 
   public event PropertyChangedEventHandler PropertyChanged; 
   public void OnPropertyChanged(PropertyChangedEventArgs e) 
   { 
       if (PropertyChanged != null) 
          PropertyChanged(this, e); 
   } 
}

private string name; 
public string Name; 
{ 
    get { return name; } 
    set { 
           name = value; 
           OnPropertyChanged(new PropertyChangedEventArgs("Name")); 
        } 
} 

3.PropertyName cambiado

El surgimiento de un evento para cada propiedad con un nombre especificado (fe NameChanged). El evento debe tener este nombre y tú debes manejarlo / subirlo. Enfoque similar a 2.

4. Obtener el enlace

Utilizando FrameworkElement.GetBindingExpression() puede obtener el objeto BindingExpression y llamar a BindingExpression.UpdateTarget() para actualizar.

Primero y segundo son los más probable dependiendo de cuál es su objetivo.

Con todo, es Visual vs Data.

Answer 4

Por lo que sé, DependencyProperty solo se requiere cuando lo necesita

1. Heredación PropertyValue
2. necesita permitir que la propiedad se establezca en Setters de Estilo
3. Use animación para la propiedad

etc.

Estas características no estarán disponibles con las propiedades normales.

Answer 5

DependencyProperty es obligatorio si desea permitir que se establezca un enlace en la propiedad. Usualmente esto es para UIElement personalizado que usted crea. Desea permitir que las personas puedan vincular datos a sus UIElement .

<local:MyUIElement MyProperty={Binding Path=SomethingToBindTo} />

Para hacer esto, se requiere que MyProperty sea una propiedad dependiente