Cómo convencer a mis compañeros de trabajo de que no utilicen conjuntos de datos para el desarrollo empresarial (.NET 2.0+)

Question

Todas las personas con las que trabajo están obsesionadas con el enfoque centrado en datos para el desarrollo empresarial y odian la idea de utilizar colecciones/objetos personalizados.¿Cuál es la mejor manera de convencerlos de lo contrario?

Answer 1

Si está trabajando en código heredado (por ejemplo, aplicaciones trasladadas de .NET 1.x a 2.0 o 3.5), sería una mala idea apartarse de los conjuntos de datos.¿Por qué cambiar algo que ya funciona?

Sin embargo, si está creando nuevas aplicaciones, hay algunas cosas que puede citar:

• Apelar a experimentar dolor en el mantenimiento de aplicaciones que se adhieren a DataSets
• Cite los beneficios de rendimiento para su nuevo enfoque
• Cebílos con un buen término medio.Pase a .NET 3.5 y promueva LINQ a SQL, por ejemplo:Si bien se sigue apegando a la arquitectura basada en datos, es un cambio enorme hacia los conjuntos de datos indexados por cadenas, y se aplica...¡voilá!Colecciones personalizadas, de una manera oculta para ellos.

Lo importante es que sea cual sea el enfoque que utilice, sea coherente y sea completamente honesto con los pros y los contras de sus enfoques.

Si todo lo demás falla (por ejemplo, tiene un equipo de desarrollo que se niega por completo a abandonar las viejas prácticas y se muestra escéptico a la hora de aprender cosas nuevas), esta es una señal muy, muy clara que has superado a tu equipo, ¡es hora de dejar tu empresa!

Answer 2

Hazlo con el ejemplo y pisa con cuidado.Cualquier cosa más fuerte simplemente te alejará del resto del equipo.

Recuerde considerar la posibilidad de que estén descubriendo algo que usted se ha perdido.Ser parte de un equipo significa turnarse para aprender y enseñar.

Ninguna persona tiene todas las respuestas.

Answer 3

Recuerde considerar la posibilidad de que estén descubriendo algo que usted se ha perdido.Ser parte de un equipo significa turnarse para aprender y enseñar.

Secundado.La idea de que el "desarrollo empresarial" es de algún modo distinto del desarrollo normal (y normalmente la implicación es "más importante que") realmente me molesta.

Si realmente existe un beneficio al usar alguna tecnología, entonces necesitarás elaborar una lista considerada de todos los pros y los contras que ocurrirían si cambiaras.
Presente esta lista a sus compañeros de trabajo junto con explicaciones y ejemplos para cada uno.

Tienes que ser realista al crear esta lista.No puedes simplemente decir "¡¡¡Nos ahorra mucho tiempo!!!¡¡GANAR!! " sin abordar el hecho de que a veces tomará MÁS tiempo, requerirá X meses para ponerse al día con la nueva tecnología, etc.Debe mostrar ejemplos concretos en los que ahorrará tiempo y exactamente cómo.

Del mismo modo, no puedes simplemente eludir los inconvenientes como si no importaran, tus compañeros de trabajo voluntad llamarte por ello.
Si no haces estas cosas, o das la impresión de que simplemente impulsas lo que te gusta personalmente, nadie te tomará en serio y te ganarás la reputación de ser el tipo que está lleno de entusiasmo y energía pero que no tiene idea. acerca de todo.

POR CIERTO.Esté atento a esta estafa en particular.Superará a todo, a menos que tengas un lote de casos sólidos para todas tus otras cosas:

• Requiere más de 12 meses de trabajo para trasladar nuestro código existente.Tú pierdes.

Answer 4

Eso sí, "depende" de la situación.A veces, los conjuntos de datos o las tablas de datos son más adecuados, por ejemplo, si realmente se trata de una lógica empresarial bastante ligera, una jerarquía plana de entidades/registros o presenta algunas capacidades de control de versiones.

Las colecciones de objetos personalizados brillan cuando desea implementar un jerarquía/gráfico profundo de objetos que no se pueden representar eficientemente en tablas 2D planas.Lo que puede demostrar es un gran gráfico de objetos y lograr que ciertos eventos se propaguen por las ramas correctas sin invocar objetos inapropiados en otras ramas.De esa manera, no es necesario recorrer o seleccionar todos y cada uno de los DataTable solo para obtener los registros secundarios.

Por ejemplo, en un proyecto en el que participé hace dos años y medio, había un módulo de interfaz de usuario que se supone que muestra preguntas y controles de respuesta en un único WinForms DataGrid (para ser más específico, era UltraGrid de Infragistics).Algunos requisitos más complicados

• El control de respuesta para una pregunta puede ser cualquier cosa - cuadro de texto, opciones de casilla de verificación, opciones de botones de opción, listas desplegables o incluso para abrir un cuadro de diálogo personalizado que puede extraer más datos de un servicio web.
• Dependiendo de lo que respondió el usuario, puede hacer que aparezcan más subpreguntas directamente debajo de la pregunta principal.Si más adelante se da una respuesta diferente, se debe exponer otro conjunto de subpreguntas (si las hay) relacionadas con esa respuesta.

La implementación original se escribió íntegramente en conjuntos de datos, tablas de datos y matrices.La cantidad de recorridos por los cientos de filas de varias tablas era puramente alucinante.No ayudó que el programador viniera con experiencia en C ++ al intentar árbitro todo (hola, los objetos que viven en el montón usan variables de referencia, ¡como punteros!).Nadie, ni siquiera el programador original, podría explicar por qué el código hace lo que hace.Entré en escena más de seis meses después de esto y todavía estaba inundado de errores.No es de extrañar que el desarrollador de segunda generación del que tomé el mando decidiera renunciar.

Después de dos meses de intentar arreglar el caos caótico, me encargué de rediseñar todo el módulo para convertirlo en un gráfico orientado a objetos para resolver este problema.sí, completo con clases abstractas (para representar diferentes controles de respuesta en una celda de la cuadrícula según el tipo de pregunta), delegados y eventos.El resultado final fue un dataGrid 2D vinculado a una profunda jerarquía de preguntas, ordenadas naturalmente según la disposición entre padres e hijos.Cuando la respuesta de una pregunta de los padres cambiaba, generaba un evento en las preguntas de los niños y automáticamente mostraban/ocultaban sus filas en la cuadrícula de acuerdo con la respuesta de los padres.Sólo los objetos cuestionables que se encontraban en ese camino se vieron afectados.La capacidad de respuesta de la interfaz de usuario de esta solución en comparación con el método anterior fue de órdenes de magnitud.

Answer 5

Irónicamente, quería publicar una pregunta que fuera exactamente lo opuesto a esto.La mayoría de los programadores con los que he trabajado han optado por el enfoque de colecciones/objetos de datos personalizados.Me rompe el corazón ver a alguien con su definición de tabla de SQL Server abierta en un monitor, escribiendo lentamente una clase contenedora de filas coincidente en Visual Studio en otro monitor (completa con propiedades privadas y captadores-establecedores para cada columna).Es especialmente doloroso si también son propensos a crear tablas de 60 columnas.Sé que existen sistemas ORM que pueden crear estas clases automáticamente, pero he visto que el enfoque manual se usa con mucha más frecuencia.

Las elecciones de ingeniería siempre implican compensaciones entre los pros y los contras de las opciones disponibles.El enfoque centrado en DataSet tiene sus ventajas (representación en memoria similar a una tabla de base de datos de datos de base de datos reales, clases escritas por personas que saben lo que están haciendo, familiares para un gran grupo de desarrolladores, etc.), al igual que los objetos de datos personalizados. (verificación de tipo compilación, los usuarios no necesitan aprender SQL, etc.).Si todos los demás en su empresa siguen la ruta de los DataSet, es al menos técnicamente posible que los DataSets sean la mejor opción para lo que están haciendo.

Answer 6

Los conjuntos de datos/tablas no son tan malos, ¿verdad?

El mejor consejo que puedo dar es usarlo tanto como pueda en su propio código y, con suerte, a través de revisiones por pares y correcciones de errores, los otros desarrolladores verán cómo el código se vuelve más legible.(Asegúrese de insistir en el momento en que ocurran estos sucesos).

En última instancia, si el código funciona, entonces el resto es semántica, en mi opinión.

Answer 7

Supongo que puedes intentar vender la idea de herramientas de mapeo y mapeo O/R.El beneficio de tratar las filas como objetos es bastante poderoso.

Answer 8

Creo que deberías concentrarte en la actuación.Si puede crear una aplicación que muestre la diferencia de rendimiento al usar conjuntos de datos frente a entidades personalizadas.Además, intente mostrarles los principios del diseño impulsado por el dominio y cómo encaja con los marcos de las entidades.

Answer 9

No lo conviertas en una discusión sobre religión o fe.Esos son difíciles de ganar (y de todos modos no es lo que quieres)

No lo formule como acaba de hacerlo en su pregunta.La cuestión no es lograr que nadie esté de acuerdo en que de esta manera o de aquella es la forma general en que deberían trabajar.Se debe hablar de cómo cada uno necesita pensar para tomar la decisión correcta en un momento dado.Dé un ejemplo de cuándo usar dataSet y cuándo no.

Hice que los desarrolladores usaran tablas de datos para almacenar los datos que obtuvieron de la base de datos y luego tuvieran un código de lógica de negocios usando esa tabla de datos...Y les mostré cómo reduje el tiempo para cargar una página de tomar 7 segundos con 100% de CPU (en el servidor web) a no poder ver la línea de CPU moverse en absoluto.cambiando el objeto de memoria de dataTable a tabla Hash.

Así que tome un ejemplo o caso en el que sea mejor implementarlo de manera diferente y gane esa batalla.No luches en una guerra de alto nivel...

Answer 10

Si la interoperabilidad es o será una preocupación en el futuro, DataSet definitivamente no es la dirección correcta a seguir.PUEDE exponer conjuntos de datos/tablas de datos a través de un servicio, pero si DEBE hacerlo o es discutible.Si está hablando de .NET->.NET, probablemente esté bien; de lo contrario, tendrá un desarrollador cliente muy descontento del otro lado de la valla consumiendo su servicio.

Answer 11

No puedes convencerlos de lo contrario.Elija un desafío más pequeño o muévase a una organización diferente.Si su gerente lo respeta, vea si puede realizar un proyecto en el estilo basado en dominio como una especie de prueba tecnológica.

Answer 12

Si puedes perfilar, simplemente hazlo y perfila.Los conjuntos de datos son más pesados ​​que un simple Collection<T>

Los lectores de datos son más rápidos que los adaptadores...

Cambiar el comportamiento de un objeto es mucho más fácil que masajear un conjunto de datos

De todos modos:Simplemente hazlo, pide perdón, no permiso.

Answer 13

A la mayoría de los programadores no les gusta salir de sus zonas de confort (tenga en cuenta que la intersección del conjunto "la mayoría de los programadores" y el conjunto "Stack Overflow" es probablemente el conjunto vacío)."Si funcionó antes (o simplemente funcionó), entonces continúa haciéndolo".El proyecto en el que estoy actualmente requirió muchos argumentos para lograr que los programadores más antiguos usaran XML/esquemas/conjuntos de datos en lugar de solo archivos CSV (la versión anterior del software usaba CSV).No es perfecto, los esquemas no son lo suficientemente sólidos para validar los datos.Pero es un paso en la dirección correcta.El código que desarrollo utiliza abstracciones OO en los conjuntos de datos en lugar de pasar objetos del conjunto de datos.Generalmente, es mejor enseñar con el ejemplo, un pequeño paso a la vez.

Answer 14

Ya hay muy buenos consejos aquí, pero aún tendrá trabajo para convencer a sus colegas si todo lo que tiene para respaldarlo son algunos comentarios de apoyo en stackoverflow.Y, si son tan escépticos como parecen, necesitarás más munición.Primero, obtenga una copia de "Patrones de arquitectura empresarial" de Martin Fowler, que contiene un análisis detallado de una variedad de técnicas de acceso a datos.Léelo.Luego oblígalos a todos a leerlo.

Trabajo hecho.

Answer 15

Centrado en datos significa menos complejidad de código.

Los objetos personalizados significan potencialmente cientos de objetos adicionales para organizar, mantener y, en general, vivir con ellos.También será un poco más rápido.

Creo que es realmente una cuestión de complejidad del código versus rendimiento, que puede responderse según las necesidades de su aplicación.

Answer 16

Empieza pequeño.¿Existe alguna aplicación de utilidad que puedas utilizar para ilustrar tu punto?

Por ejemplo, en un lugar donde trabajaba, la aplicación principal tenía un proceso de compilación complicado, que implicaba cambiar archivos de configuración, instalar un servicio, etc.

Entonces escribí una aplicación para automatizar el proceso de construcción.Tenía una interfaz de usuario de WinForms rudimentaria.Pero como nos estábamos moviendo hacia WPF, lo cambié a una interfaz de usuario de WPF, manteniendo también la interfaz de usuario de WinForms, gracias a Model-View-Presenter.Para aquellos que no estaban familiarizados con Model-View-Presenter, era un ejemplo fácilmente comprensible al que podían consultar.

De manera similar, busque algo pequeño donde pueda mostrarles cómo se vería una aplicación que no sea DataSet sin tener que realizar una inversión importante en desarrollo.