oop - programming - programación orientada a objetos
Cómo convencer a mis compañeros de trabajo de no usar datasets para el desarrollo empresarial(.NET 2.0+) (16)
Ya hay algunos consejos muy buenos aquí, pero aún tendrá un trabajo para convencer a sus colegas si todo lo que tiene que respaldarlo son algunos comentarios de apoyo sobre stackoverflow. Y, si son tan escépticos como suenan, vas a necesitar 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ígales a todos a leerlo.
Trabajo hecho.
Todas las personas con las que trabajo están obsesionadas con el enfoque centrado en los datos para el desarrollo empresarial y odian la idea de usar colecciones / objetos personalizados. ¿Cuál es la mejor manera de convencerlos de lo contrario?
Recuerda considerar la posibilidad de que estén en algo que te has 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 de (y generalmente la implicación es "más importante que") el desarrollo normal realmente me irrita.
Si realmente hay un beneficio en el uso de alguna tecnología, entonces deberá presentar una lista detallada de todos los pros y contras que ocurrirían si cambiara.
Presente esta lista a sus compañeros de trabajo junto con explicaciones y ejemplos para cada uno.
Debe 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, se necesitarán X meses para acelerar la nueva tecnología, etc. Debe mostrar ejemplos concretos en los que ahorrará tiempo y exactamente cómo.
Del mismo modo, no puede simplemente pasar por encima de las contras como si no importasen, sus compañeros de trabajo lo llamarán.
Si no haces estas cosas, o si te encuentras simplemente empujando lo que a ti personalmente te gusta, nadie te tomará en serio, y obtendrás una reputación de ser el tipo que está lleno de entusiasmo y energía, pero no tiene idea acerca de todo.
Por cierto. Cuidado con esta estafa en particular. Triunfará todo, a menos que tengas muchos casos fuertes para todas tus otras cosas:
- Requiere más de 12 meses de trabajo portando nuestro código existente. Tú pierdes.
Creo que deberías enfocarte en el rendimiento. Si puede crear una aplicación que muestra la diferencia de rendimiento cuando usa DataSets vs Custom Entities. Además, intente mostrarles los principios de diseño impulsado por el dominio y cómo encaja con los marcos de la entidad.
Hazlo con el ejemplo y pisa suavemente. Cualquier cosa más fuerte te alejará del resto del equipo.
Recuerda considerar la posibilidad de que estén en algo que te has perdido. Ser parte de un equipo significa turnarse para aprender y enseñar.
Ninguna persona tiene todas las respuestas.
Los conjuntos de datos / tablas no son tan malos, ¿verdad?
El mejor consejo que puedo dar es usarlo tanto como sea posible 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 presionar el punto cuando ocurran estas ocurrencias).
En última instancia, si el código funciona, entonces el resto es semántica, es mi punto de vista.
No lo convierta en una religión o discusión de fe. Esos son difíciles de ganar (y no es lo que quieres de todos modos)
No lo enmarque como lo hizo en su pregunta. El problema no es lograr que nadie acepte que de esta manera es la forma general en la que deberían funcionar. Debería hablar sobre 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.
Tenía desarrolladores que usaban dataTables para almacenar los datos que extraían de la base de datos y luego tenían código de lógica de negocios usando esa dataTable ... Y les mostré cómo reduje el tiempo para cargar una página de 7 segundos de CPU al 100% (en la web servidor) a no ser capaz de ver la línea de CPU moverse en absoluto ... cambiando el objeto de memoria de tabla de datos a tabla Hash.
Por lo tanto, tome un ejemplo o caso que considere mejor implementado de manera diferente, y gane esa batalla. No luches contra una guerra de alto nivel ...
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, verá si puede hacer un proyecto en el estilo de dominio como una especie de prueba de tecnología.
Si está trabajando en un código heredado (por ejemplo, aplicaciones portadas de .NET 1.xa 2.0 o 3.5), entonces sería una mala idea apartarse de los conjuntos de datos. ¿Por qué cambiar algo que ya funciona?
Sin embargo, si estás creando nuevas aplicaciones, hay algunas cosas que puedes citar:
- Apelar a experimentar dolor al mantener aplicaciones que se adhieren a DataSets
- Cite los beneficios de rendimiento para su nuevo enfoque
- Cebarlos con un buen término medio. Vaya a .NET 3.5 y promocione LINQ to SQL, por ejemplo: mientras sigue apegado a la arquitectura basada en datos, es una enorme y enorme salida para los conjuntos de datos indexados por cadenas, y aplica ... ¡voila! Colecciones personalizadas de una manera que está oculta para ellos.
Lo importante es que sea cual sea el enfoque que utilice, se mantendrá constante y será completamente sincero con los pros y los contras de sus enfoques.
Si todo lo demás falla (por ejemplo, si tiene un equipo de desarrollo que se niega completamente a abandonar las prácticas anteriores y es escéptico de aprender cosas nuevas), esta es una señal muy clara de que ha superado a su equipo, es hora de dejar su empresa !
Supongo que puedes intentar vender la idea del mapeo O / R y las herramientas mapper. El beneficio de tratar filas como objetos es bastante poderoso.
Si puede crear un perfil, simplemente hazlo y perfil. Los conjuntos de datos son más pesados que una simple Collection<T>
Los DataReaders son más rápidos que los adaptadores ...
Cambiar el comportamiento en un objeto es mucho más fácil que masajear un conjunto de datos
De todos modos: solo hazlo, pide perdón, no permiso.
Por supuesto, "depende" de la situación. A veces, los DataSets o DataTables son más adecuados, como si realmente fuera una lógica de negocios bastante ligera, una jerarquía plana de entidades / registros, o con algunas capacidades de control de versiones.
Las colecciones de objetos personalizados brillan cuando se desea implementar una 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 hacer que ciertos eventos se propaguen por las ramas correctas sin invocar objetos inapropiados en otras ramas. De esta forma, no es necesario realizar un bucle o seleccionar a través de cada 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 suponía que mostraba controles de preguntas y respuestas en un WinForms DataGrid (para ser más específico, era UltraGrid de Infragistics). Algunos requisitos más difíciles
- El control de respuesta para una pregunta puede ser cualquier cosa : cuadro de texto, opciones de casilla de verificación, opciones de botón de opción, listas desplegables o incluso mostrar un cuadro de diálogo personalizado que puede extraer más datos de un servicio web.
- Según lo que haya respondido el usuario, puede hacer que aparezcan más subpreguntas directamente debajo de la pregunta principal. Si se da una respuesta diferente más tarde, debe exponer otro conjunto de subpreguntas (si las hay) relacionadas con esa respuesta.
La implementación original se escribió completamente en DataSets, DataTables y arrays. La cantidad de bucles a través de cientos de filas para varias tablas fue puramente alucinante. No ayudó a que el programador viniera de un fondo de C ++ que intentaba ref hacer 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 está haciendo lo que hace. Llegué a la escena más de seis meses después de esto, y aún estaba lleno de insectos. No es de extrañar que el desarrollador de segunda generación del que asumí decidiera renunciar.
Dos meses de vinculación para arreglar el desastre caótico, me encargué de rediseñar todo el módulo en un gráfico orientado a objetos para resolver este problema . yeap, completo con clases abstractas (para representar diferentes respuestas de control en una celda de la grilla dependiendo del tipo de pregunta), delegados y eventos. El resultado final fue una dataGrid 2D enlazada a una jerarquía profunda de preguntas, clasificada de forma natural de acuerdo con el arreglo padre-hijo. Cuando la respuesta de una pregunta principal cambiaba, se planteaba un evento a las preguntas de los niños y mostraban / ocultaban automáticamente sus filas en la cuadrícula de acuerdo con la respuesta de los padres. Solo los objetos de preguntas en esa ruta 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 varios órdenes de magnitud.
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 se han ido con el enfoque personalizado de objetos de datos / colecciones. 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 coincidente de fila y contenedora en Visual Studio en otro monitor (completo con propiedades privadas y setters de getters para cada columna). Es especialmente doloroso si también son propensos a crear tablas de 60 columnas. Sé que hay sistemas ORM que pueden construir estas clases de forma automática, pero he visto que el enfoque manual se utiliza con mucha más frecuencia.
Las opciones 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 db-table de los datos db 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 (comprobación de compilación, los usuarios no necesitan aprender SQL, etc.). Si todos los demás en su empresa van por la ruta del DataSet, es posible al menos técnicamente que los DataSets sean la mejor opción para lo que están haciendo.
Si la interoperabilidad es / será una preocupación más adelante, DataSet definitivamente no es la dirección correcta para entrar. PUEDE exponer DataSets / DataTables a través de un servicio, pero si DEBERÍA o es discutible. Si está hablando de .NET -> .NET, probablemente esté bien, de lo contrario, tendrá un desarrollador cliente muy infeliz del otro lado de la valla consumiendo su servicio.
centrado en datos significa menos complejidad de código.
objetos personalizados significa potencialmente cientos de objetos adicionales para organizar, mantener y en general vivir. También va a ser un poco más rápido.
Creo que es realmente una cuestión de complejidad de código frente a rendimiento, que puede ser respondida por las necesidades de su aplicación.
Empieza pequeño. ¿Hay alguna aplicación de utilidad que pueda usar para ilustrar su punto?
Por ejemplo, en un lugar donde trabajé, la aplicación principal tenía un proceso de compilación complicado, que implicaba cambiar los archivos de configuración, instalar un servicio, etc.
Así que escribí una aplicación para automatizar el proceso de compilación. Tenía una interfaz de usuario de WinForms rudimentaria. Pero dado que nos estábamos moviendo hacia WPF, lo cambié a una interfaz de usuario de WPF, manteniendo la interfaz de usuario de WinForms también, 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 referirse.
Del mismo modo, encuentre algo pequeño donde pueda mostrarles cómo se vería una aplicación que no sea DataSet sin tener que realizar una gran inversión de desarrollo.
A la mayoría de los programadores no les gusta desviarse de sus zonas de confort (tenga en cuenta que la intersección del conjunto ''más programadores'' y el conjunto ''Desbordamiento de pila'' es probablemente el conjunto vacío). "Si funcionó antes (o incluso funcionó), entonces sigue haciéndolo". El proyecto en el que estoy actualmente requirió un montón de argumentos para que los programadores más antiguos usen XML / esquemas / conjuntos de datos en lugar de solo archivos CSV (la versión anterior del software usaba los CSV). No es perfecto, los esquemas no son lo suficientemente robustos para validar los datos. Pero es un paso en la dirección correcta. El código que desarrollo utiliza abstracciones de OO en los conjuntos de datos en lugar de pasar los objetos del conjunto de datos. En general, es mejor enseñar con el ejemplo, un pequeño paso a la vez.