c# - Portar una aplicación de PowerBuilder a.NET

migration powerbuilder-conversion

Question

¿Alguien tiene algún consejo para migrar una aplicación empresarial PowerBuilder 10 a .NET?

Mi compañía está considerando migrar una aplicación de PB heredada a .NET (C #) y me pregunto si alguien tiene alguna experiencia, buena o mala, que le gustaría compartir.

La aplicación es bastante grande con 10 bibliotecas PBL, algunas PFC y marcos personalizados. También se está realizando una gran cantidad de llamadas a DLL. Por último, utiliza una base de datos de Microsoft SQL Server.

Hemos discutido cómo portar el código de la aplicación "core" a .NET y luego aportar funciones más avanzadas según sea necesario.

Answer 1

Mi teoría favorita de la semana es que los desarrolladores de PowerBuilder dan por sentado el DataWindow hasta que tienen que reproducir toda la funcionalidad que viene incorporada.

Yo apoyaría esa teoría. Pasé por un intento de conversión de PB8 a Java en un proyecto hace varios años que fracasó estrepitosamente, incluso utilizando la primera generación de DataWindow HTML. Mi empleador actual está empeñado en mudarse a C #, no usar Datawindow.NET a pesar de los 2W DWO en nuestro producto actual. No espero con ansias el día en que se establezca la realización. (El producto completo consta de varias aplicaciones de usuario, más de una docena de servicios y uso de aproximadamente 70 PBD)

OP: a menos que su aplicación esté inusualmente bien estructurada (originalmente escrita para EA Server, tal vez?), Esto no será un puerto. Las cosas funcionan de manera muy diferente en los entornos PB y .NET para que un puerto plano funcione satisfactoriamente. No puedo enfatizar esto lo suficiente: si realmente está usando el modelo de evento PB, un "puerto" probablemente será un fracaso.

Debe observar el flujo lógico (UI y proceso entrelazados), el flujo de control (quién posee el proceso o los datos en este momento ), el acceso a los datos (UI, capa de datos, ??) y las partes del modelo de eventos DW que está utilizando. del código. Si está pensando en ASP.NET (como lo somos nosotros), toda su experiencia de interacción con el usuario tendrá que cambiar, y eso se reflejará en las otras consideraciones.

No relacionado directamente con el código, la automatización de la compilación cambiará (usamos PowerGen para compilaciones PB consistentes; MSBuild es muy diferente) al igual que su instalación y configuración.

Answer 2

Creo que cualquiera que esté considerando esto para una gran aplicación sería una locura no considerar seriamente el uso de DataWindow.NET, para no perder su inversión en los DW.

Answer 3

Creo que gbjbaanb te dio una buena respuesta arriba.

Algunas otras preguntas que vale la pena considerar:

• ¿Es esta aplicación PB10 una nueva aplicación PB10 bien escrita o fue creada en 1998 en PB4 y luego se convirtió gradualmente a PB10 a lo largo de los años? Una aplicación bien escrita debería tener cierta separación decente entre la lógica de negocios y la GUI, y debería poder portar sistemáticamente su código a .Net. Al menos, debería ser mucho más fácil que si se trata de una aplicación PB heredada, en cuyo caso es probable que tengas un montón de lógica enterrada en botones, ventanas de datos, menús y quién sabe qué más. No imposible, pero más difícil de volver a trabajar.
• ¿Qué tan bien está funcionando la aplicación? Si está bien y es estable, y no necesita muchas características nuevas, entonces tal vez no sea necesario volver a escribir. O, como dijo gbjbaanb, puede colocar envoltorios .Net alrededor de algunas piezas y luego exponer la funcionalidad que necesita sin una reescritura completa. Si, por otro lado, su aplicación es difícil, desagradable, no satisface realmente las necesidades comerciales y está haciendo que sus usuarios sean ineficientes, entonces es posible que tenga un caso de reescritura, o quizás una refactorización seria y luego algunas mejoras. Hay tipos de PB que sirven oraciones, eh, me refiero a ganarse la vida con el segundo escenario.

No estoy en contra de volver a escribir si el software es extremadamente pobre y afecta negativamente el negocio de la empresa, pero incluso entonces los ajustes y mejoras graduales son una forma menos riesgosa de lograr la evolución del sistema.

Además, no abandones este hilo hasta que Terry Voth publique. Está en y es uno de los mejores pilotos de PB.

Answer 4

Cuando vi el título, solo estaba acechando, siendo un renombrado fanático del PB. Oh bien. Gracias por el voto de confianza, Bernard.

Mi primera sugerencia sería abandonar el lenguaje del autoengaño. Si como la mitad de un pastel de queso "ligero", todavía voy a perder de vista mi cinturón. Una migración puede tomar tan poco como 10 minutos. Lo que vas a hacer es reescribir . El tiempo necesita ser medido como reescritura. El riesgo debe ser medido como una reescritura. Y el esfuerzo de diseño debe medirse como una reescritura.

Sí, dije esfuerzo de diseño. "Migrar" evoca imágenes de código de bombeo a través de un cuadro negro con una traducción que refleja el original que sale del otro lado. ¿Desea replicar los mismos errores de diseño que se cometieron en 1994 con los que ha estado viviendo durante años? Incluso con un código de excelente calidad, supongo que las excelentes opciones de diseño en PowerBuilder pueden ser terribles en C #. ¿Una conversión directa descuida los poderes y fortalezas de la plataforma? ¿ Vivirá con las consecuencias de descuidar un buen diseño de C # durante los próximos 15 años?

Aparte de eso, ya que no mencionas tu motivación para cambiarte a .NET, es difícil sugerir qué opciones podrías tener para mitigar el riesgo de una reescritura. Si su administración simplemente ha decidido que los desarrolladores de PowerBuilder huelen mal y necesitan ser eliminados de la oficina, buena suerte en la reescritura.

Si simplemente desea implementar Windows Forms, Web Forms, Assemblies o servicios web .NET, o aprovechar las bibliotecas .NET, entonces, como mencionó Paul, pasar a 11.0 u 11.5 podría llevarlo allí, con un esfuerzo más cercano a una migración. (Le sugiero que revise nuevamente y me asegure de que tiene un buen diseño para la nueva plataforma, especialmente con Web Forms, pero ese esfuerzo debería ser significativamente más pequeño que una reescritura). Si desea implementar una aplicación WPF, lo sé. un año es bastante tiempo para esperar, pero vale la pena mirar en PowerBuilder 12. Desactivada correctamente, la capacidad WPF puede poner a PowerBuilder en una posición única y poderosa.

Si se garantiza que una reescritura estará en su futuro (las duchas parecen más baratas), es posible que desee realizar la conversión de fase. DataWindow.NET le permite llevar sus DataWindows con usted. (Mi teoría favorita de la semana es que los desarrolladores de PowerBuilder dan por sentado el DataWindow hasta que tienen que reproducir toda la funcionalidad que viene incorporada). Ser capaz de eliminar los preexistentes, los pre-probados, las múltiples filas, el desplazamiento, el mínimo Una IU dinámica que consume recursos, imprimible y enlazada a datos, generando un mínimo de SQL con un bloqueo de registro lógico incorporado y conversión de errores de la base de datos a eventos, en una nueva aplicación es una gran ventaja.

También puede realizar la transición en fase convirtiendo su código de PowerBuilder en algo que es consumible por una aplicación .NET. Como se mencionó, puede producir objetos COM con el PB 10 que tiene, pero tendrá que moverse a 11.0 u 11.5 para producir ensamblajes. El valor de esto puede depender de cuán particionada esté su aplicación. Si su lógica empresarial se filtra a través de eventos y funciones de la GUI en lugar de ser particionada en objetos no visuales (también conocidas como clases personalizadas), el valor de esto puede ser cuestionable. Aún así, este es un paso en falso de diseño que probablemente debería solucionarse antes de una conversión completa a C #; Esto es algo que se puede hacer mientras se mantiene la aplicación PowerBuilder como un paso preliminar a una fase y luego a una conversión completa.

Sin duda preferiría verte en PowerBuilder. De no ser así, me gustaría verte triunfar. Solo recuerda, una vez que tomes ese primer bocado, tendrás que terminarlo .

Buena suerte encontrando ese cinturón,

Terry

Veo que mencionaste mover "componentes principales" a .NET para comenzar. Como ya puede adivinar, creo que un enfoque por etapas es una decisión acertada. Ahora la definición de "núcleo" puede ser discutible, pero ¿qué hay de un punto de vista contrario? ¿Comida para el pensamiento? (Obviamente, esta fue la semana equivocada para comenzar una dieta). En función de dónde se encuentra PB en este momento, sería difícil dividir su aplicación entre PB y C # junto con la funcionalidad de la aplicación (por ejemplo, Cuentas por cobrar en PB, Cuentas por pagar en C #). Una división que puede funcionar es GUI vs lógica de negocios. Como se mencionó anteriormente, el bombeo de la lógica empresarial del PB a los ejecutables que C # puede consumir ya es posible. ¿Qué tal crear la GUI en C #, con los DataWindows copiados de PB y la lógica de negocios bombeada como objetos o ensamblajes COM? Yendo hacia el otro lado, para consumir los ensamblados .NET en PB, tendrá que moverse hasta 11.x y migrar a Windows Forms, o colocarlos en un envoltorio que se pueda llamar COM .

O simplemente entrene a sus desarrolladores de C # en PowerBuilder. Esto puede ser un rumor, pero escuché que la nueva línea de etiquetas de marketing de PowerBuilder será "Tan simple, que incluso un desarrollador de C # puede usarlo". ;-)

Answer 5

Es posible que desee pasar un tiempo investigando PowerBuilder 11.5 (recientemente lanzado), que agrega una integración significativa de .NET.

La migración a PowerBuilder 11.5 para hacer uso del nuevo código .NET será mucho más fácil que reescribir completamente la aplicación completa en C #.

Answer 6

Los PHB de las grandes corporaciones piensan que Powerbuilder es un lenguaje de juguete y migrar a un nuevo idioma como C # es trivial y se puede hacer a bajo costo. De hecho, migrar una aplicación PB a cualquier otro idioma costará al menos tanto como desarrollar una aplicación completamente nueva en el nuevo idioma. La aplicación resultante generalmente perderá funcionalidad en comparación con la original y dará como resultado la insatisfacción del usuario. He visto varios intentos, todos han fallado debido a la dificultad y los problemas del usuario.

Si no está roto, no lo arregles.

Answer 7

No sé si es bueno o no, pero revise este producto (comercial): PB.Net

Answer 8

Sí, es factible ahora sin reescribir el período de componentes del servicio.

PB 12.5>

Y dirija las migraciones e integraciones de la GUI y los componentes del servicio a c #.

La estrategia de migración / integración puede variar según el alcance de su proyecto, la escalabilidad, los recursos y la línea de tiempo.

Puede usar estos tipos de objetivos y proyectos en PowerBuilder .NET. Refiera este enlace a Sybase_PB .Net

• Aplicación de ventana WPF Aplicación de ventana WPF, Proxy de cliente WCF o Proxy de cliente REST
• PB Assembly WCF Client Proxy, REST Client Proxy o PB Assembly
• .NET Assembly WCF Client Proxy, REST Client Proxy, o .NET Assembly
• Servicio WCF Proxy de cliente WCF, Proxy de cliente REST o Servicio WCF

Answer 9

Si es bastante grande, podría tener mejores resultados al escribir un front-end para él en .net (o una GUI basada en la web) y usarlo para interactuar con su código PB, suponiendo que pueda exponer la funcionalidad como una API.

Si está utilizando PB 9 o superior, puede generar dll COM o .NET , que luego puede consumir mediante una GUI de C #. Recomendaría esto sobre una reescritura en cualquier idioma nuevo.

Recuerde, las reescrituras nunca son una bala de plata, siempre terminan consumiendo más tiempo, son difíciles y están llenas de errores de lo que esperaba.