Dependencia en DependencyObject y DependencyProperty

Question

Estoy creando una aplicación Silverlight y una de mis advertencias de la última vez fue que si necesita hacer algo de manera correcta en Silverlight / WPF, tendría que modelar sus objetos como DependecyObject y usar DependencyProperty (ies)

Considero que este modelo es bastante engorroso, requiere campos estáticos e inicializadores en la mitad de las clases que utilizo. ¿Es una buena idea usar el evento antiguo (patrón de observador?) en lugar de DependencyObject? / p>

Mi objetivo es minimizar las placas de inflado y calderas del código (las odio) y realmente me gustaría saber si alguien con experiencia en Silverlight / WPF tiene algún consejo / técnica para mantener el uso de DependencyObject y DependencyProperty a un mínimo?

¿Es esta una buena idea?

Answer 1

En realidad, en Silverlight no puede heredar DependencyObjects, por lo que debe (y debe) implementar INotifyPropertyChanged en su lugar.

La implementación de INotifyPropertyChanged tiene muchas ventajas sobre DependencyObjects (abreviaré este DO para hacerlo más fácil) y usar DependencyProperties (DPs):

• Esto es más ligero
• Le permite más libertad para modelar sus objetos
• Se puede serializar fácilmente
• Puede elevar el evento cuando lo desee, lo que puede ser útil en ciertos escenarios, por ejemplo, cuando desea agrupar varios cambios en una sola operación de UI, o cuando necesita elevar el evento incluso si los datos no lo hicieron. cambio (para forzar el redibujado ...)

Por otra parte, la herencia de DO en WPF tiene las siguientes ventajas:

• Más fácil de implementar, especialmente para principiantes.
• Obtienes un mecanismo de devolución de llamada (casi) de forma gratuita, lo que te permite recibir notificaciones cuando el valor de la propiedad cambia
• Obtiene un mecanismo de coerción que le permite definir reglas para el valor máximo, mínimo y presente de la propiedad.

Hay otras consideraciones, pero estas son las principales.

Creo que el consenso general es que los DP son excelentes para los controles (y puede implementar un CustomControl con DP personalizados incluso en Silverlight), pero para los objetos de datos debería implementar INotifyPropertyChanged.

HTH, Laurent

Answer 2

Realmente depende de a qué objetos te refieres. Si se pretende que el objeto se asiente en el árbol XAML, es mejor usar DependencyProperties (y, por lo tanto, heredar DependencyObject, lo que hacen todos los UIElements) para permitir todos los beneficios que las DependencyProperties proporcionan (que son animables, vinculantes, herencia hereditaria automática opcional, etc.). Le recomiendo que lea la descripción general de MSDN en DependencyProperties si tiene t ya.

Si el objeto es una entidad de datos (es decir, está vinculando sus valores A algo en el árbol XAML), no hay necesidad de heredar de DependencyObject. Si las propiedades del objeto son de lectura y escritura, es posible que desee implementar INotifyPropertyChanged , que permitirá que los enlaces se actualicen automáticamente cuando el valor cambie.

Answer 3

Estoy de acuerdo con Richard en que depende del propósito de su clase, pero como nota parece que PUEDE heredar de DependencyObject directamente en Silverlight 2.0 Release, sin tener que heredar de UIElement o UserControl. Al menos, lo estoy haciendo en mi aplicación (SilverLight 2.0 RTW).

System.Windows.DependencyObject on MSDN

  

no es típico se deriva directamente de DependencyObject para la mayoría de los escenarios. En su lugar, puede derivar de un control específico, de una de las clases base de control (ContentControl; Control; ItemsControl), de FrameworkElement o de clases que no son de control que aún participan en la IU, como Panel o Grid. Derivar de DependencyObject puede ser apropiado si está definiendo un objeto de almacenamiento de datos o negocio en el que desea que estén activas las propiedades de dependencia, o si está creando una clase de soporte de servicio que será propietaria de propiedades adjuntas.

HTH