Inicio Blog Reflexiones sobre el desarrollo - Permítanme enumerar las razones

Reflexiones sobre el desarrollo - Permítanme enumerar las razones

Patrick Chen | 13 de abril de 2021

Reflexiones sobre el desarrollo - Permítanme enumerar las razones

Hace poco, estaba trabajando en un código especialmente complejo que requería mucha manipulación de datos, agrupación, ordenación, etc. y tuve un descubrimiento que espero pueda resultar útil a otros desarrolladores.

Normalmente, al extraer datos de Acumatica, me siento cómodo extrayendo datos en objetos PXResultSet y recorriendo los resultados en un bucle Foreach. Este patrón suele ser suficiente para la mayoría de las tareas. La nueva tarea, sin embargo, requería mucho procesamiento de los datos en lugar de simplemente enumerar a través de la lista. Además, el rendimiento era una preocupación, por lo que quería minimizar el número de veces que iba a la capa de datos. Por ambas razones, quería mantener mis datos independientes de la caché. Lo que tenía que hacer era extraer los datos en un objeto IEnumerable y luego recorrerlo, filtrarlo, copiarlo y manipularlo mediante operaciones LINQ . Inicialmente, tuve problemas para conseguir PXResultSets en una lista. No era capaz de traducirlo directamente a la lista que necesitaba. Entonces descubrí lo siguiente en el código fuente.

Var ListofLines = SelectFrom<SOShipLine>.View.Select(this).RowCast<SOShipLine>().ToList();

La llamada RowCast refactoriza el PXResultSet en una lista de los objetos que se pasan en la llamada. Si no estás familiarizado con la tecnología, este es un buen momento para repasar tu nomenclatura C# LINQ. Para mí, manipular datos en la capa de aplicación supuso una gran mejora de la eficiencia en términos de realización de tareas de programación y de rendimiento del sistema. Encuentro dos escenarios comunes en mi código donde este patrón puede producir beneficios.

Escenario uno: predicados BQL complicados

En lugar de formular complicadas predicciones BQL que agrupen por, sumen, calculen, etc., vuelco un conjunto de datos en una lista y lo manipulo mediante LINQ. Esto resulta especialmente útil si se buscan datos varias veces en el mismo CAD. Es ciertamente más legible que una larga sentencia BQL. En el código siguiente, el método I es un patrón típico extraído de la fuente de Acumatica. El método II es una versión que extrae datos con una cláusula Where pero deja la agrupación a la capa de aplicación. La ventaja aquí es que también pude obtener fácilmente un recuento distinto y, posteriormente, puedo consultar los datos originales sin agrupar con facilidad. También es posible que se obtengan mejoras de rendimiento en función de la carga/arquitectura del sistema de la instancia concreta de Acumatica.

GIST: https://gist.github.com/patrick711/bea38c39e1324c20cae5c56cddba6e9f

Segundo escenario: conjuntos de datos

Creo que a medida que el código se vuelve complejo, es importante tener en cuenta las necesidades de datos del conjunto de código desde una perspectiva descendente. Cuando se codifican tareas complicadas, es fácil quedar atrapado en la maleza y encontrarse a sí mismo sondeando el mismo DAC varias veces para realizar tareas separadas. Esto puede ser especialmente cierto si eres bueno escribiendo bloques de código modular. Una de las maneras más fáciles de detectar esto es pensando en la actualización de bucles anidados. Si tiene un bucle anidado que extrae datos, un Foreach típico con un PXSelect, disparará el PXSelect cada vez que el bucle superior itere. En lugar de iterar una llamada a la capa de datos cada vez, puede considerar extraer un conjunto de datos más grande una vez por encima del bucle y filtrar el conjunto para cada iteración del bucle. En el método II que se muestra a continuación, extraigo un conjunto de cuentas con cuentas de nivel superior antes de que comience el bucle. Pero espere, se preguntará, ¿por qué no extraer todas las cuentas para ambos bucles? Eso podría ser genial, especialmente si necesita esos datos para otras tareas o si tiene una buena idea del conjunto de datos resultante. Sin embargo, también podría estar extrayendo un conjunto de datos innecesariamente grande que borraría cualquier ganancia de rendimiento que pudiera obtener. Como siempre, es importante tener en cuenta la topología de los datos.

GIST: https://gist.github.com/patrick711/49a7a0e361f0acb17742f162da16e773

Estos ejemplos se presentan como una forma de hacer el código más legible, aprovechar las capacidades nativas de C#, y potencialmente encontrar eficiencias de rendimiento. Espero que te haya sido útil, ¡feliz programación!

Autor del blog

Patrick es el desarrollador principal de SPS Commerce EDI para Acumatica. Está totalmente certificado como desarrollador de Acumatica y lleva trabajando con el producto desde 2013. Lleva más de 17 años desarrollando software a medida en el sector de los ERP.

Reciba las actualizaciones del blog en su bandeja de entrada.