¿A la propiedad, o no a la propiedad?

Question

Estoy tratando de averiguar qué me daría el mejor código. Lo cual es un poco subjetivo, por supuesto, me doy cuenta.

Tengo una aplicación que accede a una base de datos para la cual he escrito un conjunto que oculta detalles sobre esta base de datos de todas las aplicaciones que hacen uso de este conjunto.

También tengo una aplicación WPF que hace uso de este ensamblaje para mostrar varios cálculos de costos en los que me gustaría usar databinding.

La vinculación de datos solo es posible para las propiedades de los objetos (en la medida en que llegué a trabajar). Esto significaría que necesitaría un objeto, preferiblemente con el soporte de INotify y una variedad de objetos. Sin embargo, preferiría mantener cosas de INotify y WPF fuera del ensamblado que maneja el acceso a la base de datos.

¿Cómo resuelven esto los demás: mantener las cosas WPF fuera de la capa de la base de datos (como INotify) y dentro de su WPF permitir el enlace? Escribir un envoltorio? ¿O la mayoría de la gente pone una clase 'property'/'INotify' como objeto de transferencia de datos directamente en la capa de la base de datos?

Answer 1

Estás trabajando bajo un concepto erróneo. INotifyPropertyChanged es no una cosa de WPF. Considere lo siguiente:

1. Es parte de System.dll
2. Es en el System.ComponentModel espacio de nombres
3. Ha sido parte de en NET Framework desde la versión 2.0
4. Es apoyado por la mayoría de los objetos de datos NET Framework de cada la caja que incluye DataRowView de ADO.NET y ObservableCollection de ComponentModel.
5. Es utilizado automáticamente por WinForms, ASP.NET, WPF y muchos paquetes de terceros para interactuar con objetos de datos.

Dado que todas las capas de datos generadas automáticamente que produce Microsoft implementa INotifyPropertyChanged, ¿por qué debería tratar su capa de datos de forma diferente?Obviamente, su capa de datos necesita notificar a sus clientes de alguna manera cuando las propiedades cambian. ¿Por qué no utilizar el mecanismo incorporado de NET Framework?

En mi opinión cualquier capa de datos que contenga objetos mutables debería implementar notificaciones de cambio de propiedad como una cuestión de curso. INotifyPropertyChanged fue diseñado para ser un mecanismo de notificación, ¿por qué no usarlo como estaba previsto?

En una nota más general: la adición de una capa de envoltura adicional generalmente es solo una falta de código ineficiente. Algunas veces es necesario e incluso beneficioso, pero no lo haga solo por el simple hecho de hacerlo. Muchas veces los objetos de capa de datos diseñados razonablemente funcionan muy bien como modelos de vista. Solo cuando el modelo de vista diverja de su capa de datos o donde necesite funcionalidad adicional, debe considerar la introducción de una complejidad adicional, y solo caso por caso.

Answer 2

Creo que la solución más limpia es escribir un objeto envoltorio en su ensamblaje WPF y mantener los tipos INotify fuera del ensamblaje de la base de datos. No hay ninguna razón para agregar la complicación de INotify a la capa de la base de datos a menos que proporcione una ventaja específica.

Answer 3

Otras personas lo resuelven implementando el patrón de diseño MVVM.

Answer 4

Escribir un contenedor. Si el envoltorio es bastante directo, incluso podría construir un generador para generar todas las clases en función de la DTO de origen

Answer 5

Puede consultar PostSharp, este es el tipo de cosa para la Programación Orientada a Aspectos (AOP). Hay un montón de examples tejiendo INotify * en clases de modelo. Todavía no comencé a utilizar PostSharp en un proyecto real, pero parece prometedor en algunos escenarios de prueba en los que lo hemos probado.

Answer 6

Una cosa más señalar que es útil - si sabe que el inmueble que se une a es inmutable (es decir, un producto único objeto o algo que va a ser inicializado una vez y nunca tocado), que no lo hacen necesidad para hacerlo INotifyPropertyChanged - una propiedad simple funcionará bien.