.net - que - no se guardaron los cambios vuelve a intentarlo instagram

¿Cuándo vale la pena usar un BindingSource?

Question

Creo que entiendo bastante bien qué hace la clase BindingSource, es decir, proporciona una capa de indirección entre una fuente de datos y un control de UI. Implementa la interfaz IBindingList y, por lo tanto, también proporciona soporte para la clasificación. Y lo he usado con la frecuencia suficiente, sin demasiados problemas. Pero me pregunto si lo uso más seguido de lo que debería. Quizás un ejemplo ayudaría.

Digamos que tengo un simple cuadro de texto en un formulario (usando WinForms), y me gustaría vincular ese cuadro de texto a una propiedad simple dentro de una clase que devuelve una cadena. ¿Vale la pena usar un BindingSource en esta situación?

Ahora digamos que tengo una cuadrícula en mi formulario, y me gustaría vincularlo a una DataTable. ¿Debería usar un BindingSource ahora?

En este último caso, probablemente no utilizaría un BindingSource, ya que un DataTable, por lo que puedo deducir, proporciona la misma funcionalidad que BindingSource. El DataTable disparará los eventos correctos cuando se agrega, borra, etc. para que la cuadrícula se actualice automáticamente.

Pero en el primer caso con el cuadro de texto vinculado a una cadena, probablemente tendría la clase que contiene la propiedad de cadena implementar INotifyPropertyChanged, por lo que podría desencadenar el evento PropertyChanged cuando cambie la cadena. Utilizaría un BindingSource para poder escuchar estos eventos PropertyChanged para que pueda actualizar el cuadro de texto automáticamente cuando cambie la cadena.

¿Cómo suena esto hasta ahora? Todavía siento que hay una brecha en mi comprensión que me impide ver toda la imagen. Esta ha sido una pregunta bastante vaga hasta el momento, por lo que intentaré hacer algunas preguntas más específicas; idealmente, las respuestas harán referencia a los ejemplos anteriores o algo similar ...

(1) ¿Vale la pena usar un BindingSource en cualquiera de los ejemplos anteriores?

(2) Parece que los desarrolladores solo "suponen" que la clase DataTable hará lo correcto al activar eventos PropertyChanged en el momento adecuado. ¿Cómo se sabe si una fuente de datos es capaz de hacer esto? ¿Existe una interfaz particular que una fuente de datos debería implementar para que los desarrolladores puedan asumir este comportamiento?

(3) ¿Importa a qué control se está obligado, al considerar si se usa o no un BindingSource? ¿O es solo la fuente de datos lo que debería afectar la decisión? Quizás la respuesta sea (y esto parezca lo suficientemente lógico): el Control debe ser lo suficientemente inteligente como para escuchar los eventos PropertyChanged, de lo contrario se requiere un BindingSource. Entonces, ¿cómo se puede saber si el Control es capaz de hacer esto? Nuevamente, ¿existe una interfaz particular que los desarrolladores puedan buscar y que el Control deba implementar?

Es esta confusión la que, en el pasado, me llevó a usar siempre un BindingSource. Pero me gustaría entender mejor cuándo usar uno, de modo que lo haga solo cuando sea necesario.

Answer 1

Bastante vieja pregunta. Me pregunto por qué nadie ha respondido hasta ahora. De acuerdo, intentaré compartir cosas de mi experiencia.

Un BindingSource es más que una forma de vincular los controles a las colecciones. Después de haber trabajado en WinForms por más de una década, las mejores características de un BindingSource que más me gusta incluyen:

1. Encuadernación (¡por supuesto!)
2. Gestión de divisas (voy a llegar a eso en un segundo)
3. Un BindingSource puede actuar como una fuente de datos de otro BindingSource .

Para apreciar completamente estas características, las explicaré en el contexto de un DataSet, que es con diferencia el tipo más común de fuente de datos utilizada en WinForms, especialmente en aplicaciones de línea de negocios.

La gestión de divisas reduce el concepto de registro actual . Una DataTable es solo una colección de DataRow s, es decir, no hay ningún concepto de registro actual en DataTables. Igual es el caso de DataView (en una nota lateral, no se puede vincular directamente a un DataTable ; cuando lo haces, en realidad se une a la propiedad DefaultView de ese DataTable , que es un DataView . También puedes crear tu propio DataView ).

La gestión de divisas realmente resulta útil en el caso de la interfaz de usuario maestra / detallada. Entonces digamos que tiene un ListBox of Students en el panel izquierdo (Master), y varios TextBoxes, ComboBoxes, CheckBoxes etc. en el panel derecho, con una grilla de cursos de estudiantes seleccionados (Detalle). En su DataSet, tiene dos tablas de datos llamadas Student y Courses . En aras de la simplicidad, estoy evitando un gerundio (Student_Course) aquí. La tabla del Course tiene una clave externa StudentID . Así es como configura el enlace aquí (observe cómo las 3 características que enumeré arriba se usan en la configuración a continuación):

1. Agregue dos controles BindingSource a su formulario, denominados bsStudent y bsCourses .
2. Establezca DataSource de bsStudent en Student DataTable.
3. ¡Establezca DataSource de bsCourses en bsStudent!
4. En la propiedad DataMember , verá el nombre de la relación que existe en el DataSet entre nuestras dos tablas. Seleccionarlo!
5. Establezca el enlace de los controles atómicos individuales a las propiedades de bsStudent .
6. Establezca el DataSource de los cursos grid bsCourses.

Y tu estas listo. Sin escribir una sola línea de código (por así decirlo), ha creado con éxito una vista de detalles maestros. El control BindingSource ahora se ocupará del registro actual en la lista de Estudiantes y actualizará no solo los controles atómicos (TextBoxes, ComboBoxes, etc.), sino también la tabla de cursos, que actualizará automáticamente sus contenidos para mostrar los cursos del alumno seleccionado actualmente.

Esto, amigo mío, es el papel de BindingSource (entre otras cosas agradables como clasificar, filtrar, etc.) que me gusta más. Sin involucrar un BindingSource entre sus controles y el almacén de datos, no tendría el concepto de registro actual y, por lo tanto, tendría que administrarlo manualmente manteniendo sincronizada toda la interfaz de usuario.

Answer 2

Hola, también tengo cierta confusión sobre el tema.
Cuando uso tablas de datos esas implementan todas las interfaces.
Sin embargo, siempre uso el bindingsource solo para estar seguro ... :)

Hay algunos argumentos por los que puedo pensar

1. Múltiples vistas en el mismo conjunto de registros. (es decir, 2 cuadrículas con órdenes de clasificación / filtros diferentes)
2. Filtrar, ordenar sin cambiar el orden de los registros (Filter / Sort)
3. Posibilidad de desactivar el enlace por un tiempo por motivos de rendimiento. (cuando hay grandes actualizaciones en la tabla, no escuches todos los eventos de IXXChanged)
4. IErrorprovider nunca funcionó para mí sin un bindingsource, sin embargo, esto podría ser mi culpa.

Answer 3

También me gustaría agregar, utilizando BindingSource, puede enlazar a un objeto comercial, que puede implementar el evento INotifyPropertyChanged, de modo que si los datos se cambian (ya sea por su código o por el código de otra persona), su UI puede reflejar automáticamente las actualizaciones.