Migración de una aplicación Delphi 7 a.NET
migration (9)
Eso me parece una idea realmente mala .
¿Hay alguna ventaja tecnológica para su producto en .NET, o es una decisión política sobre todo ser una tienda de Microsoft? Para el cliente-servidor, Delphi es bastante difícil de superar. Utilicé VS2005 / 8 y realmente y sinceramente no es tan bueno como Delphi para el desarrollo de Win32. Pero si vas a migrar a la web más adelante, entonces VS tiene ventajas definitivas.
Si la gente de negocios obstinada simplemente se niega a usar Delphi nunca más, entonces KiwiBastard está en lo correcto, IMO. Convierta primero a Delphi.NET, luego migre desde allí a VS2005. O 2010, ya que es una línea de tiempo más realista :)
¿Algún consejo sobre cómo migrar una aplicación empresarial existente de Delphi 7 a .NET 2.0 en Visual Studio 2005?
Visual Studio 2005 ya ha sido comprado, la compañía quiere alejarse de las herramientas de Borland / Codegear.
La aplicación es un ejecutable de servidor de cliente único, que utiliza una serie de controles de interfaz de usuario de terceros y Crystal Reports 10 para informes.
Existe una amplia lógica de negocios distribuida entre los tipos de Delphi en la interfaz de usuario, así como en muchos procedimientos almacenados de SQL Server 2000. Mover gran parte de la lógica de proceso almacenada en clases .NET es otro objetivo.
Para reducir el impacto en los clientes, se preferiría un enfoque pieza por pieza en lugar de una re-escritura / conversión completa, si es posible. Gracias por adelantado.
[Actualizar] ¿Alguien ha tenido alguna experiencia, buena, mala o fea, utilizando Managed VCL para este tipo de escenario?
Para mí, la pregunta sería: ¿qué idioma estarías usando? Espero C # y no VB.Net. (Con toda la política incómoda en este uso, esto no está claro de ninguna manera).
Lo siguiente que probablemente escuche es que hay conversores que lo ayudarán a hacer esto. Acabamos de pasar por una evaluación de dichos convertidores (Delphi 7 a C #) y estábamos muy contentos. decepcionado.
¿Puedo sugerir un compromiso? ¿Qué hay de Delphi Prism? Es Delphi en VS2008. Claro, todavía tienes Delphi y, por lo tanto, Codegear, pero también tienes VS (como tu empresa espera que lo hagas).
Solo usted realmente puede decidir si es posible un acercamiento pieza por pieza. Por ejemplo, la aplicación puede dividirse fácilmente o todas las formas están muy unidas con toda la lógica comercial. Técnicamente es posible, pero todo depende de cómo esté realmente estructurada la base del código.
Una conversión por partes significaría cambiar el código Delphi nativo para usar COM para que el lado .NET pueda coexistir con Delphi (o posiblemente usar alguna otra tecnología, difícil de decir)
Si puede, puede ser más fácil convertir la aplicación a Delphi.NET primero, y al menos los bits .NET podrán comunicarse un poco más fácilmente.
Solo un pensamiento.
Alejarse de las herramientas de CodeGear / Borland básicamente elimina cualquier solución basada en Delphi .NET y una reescritura total de su aplicación.
Espero que mi respuesta a continuación te ayude con tus decisiones.
Por experiencia (haber reescrito una aplicación Delphi con un equipo de personas) se reduce a cualquiera de las siguientes dos opciones.
Pero primero una advertencia: tomará al menos el esfuerzo total de desarrollo que tomó escribir su aplicación actual de Delphi.
En nuestro caso, este esfuerzo estaba justificado ya que la antigua aplicación Delphi (que en realidad era Kylix) tenía un fin de vida debido a varias razones. Nuestra reescritura constaba de dos partes: reescribir con funcionalidad extra limitada seguida de mucha funcionalidad adicional (el diseño de la primera parte ya tenía en cuenta la segunda parte).
De vuelta a tus elecciones:
1- una reescritura total en C # o VB.NET en Visual Studio
2- una reutilización parcial de su código de capa de negocio existente de Delphi utilizando Oxygene de RemObjecs (un plugin de Visual Studio con una sintaxis muy similar a la sintaxis de Delphi). CodeGear ofrecerá Prism pronto (probablemente antes de finales de 2008), que también se integrará en Visual Studio.
Debido a que el acceso a datos .NET y la interfaz de usuario son totalmente diferentes de Delphi, tendrá que hacer esto desde cero (tanto para el escenario 1 como para el 2). Visual Studio 2008 ofrece muchos beneficios aquí sobre Visual Studio 2005.
No existe tal migración gradual, ya que aquí se realiza un cambio completo de la plataforma, se trata de un enfoque de todo o nada.
Ambas situaciones llevarán un tiempo considerable (aunque tengas experiencia en Delphi, acostumbrarte al mundo .NET llevará tiempo).
Visual Studio puede interactuar con Crystal Reports y funciona bien con SQL Server.
Dado que Visual Studio 2008 ofrece muchos beneficios (no solo .NET 3.5, sino también productividad), será mejor que lo haga. En el lado de la interfaz de usuario, debe hacer una elección equilibrada entre WinForms (también conocido como Windows Forms) y Windows Presentation Foundation (también conocido como WPF).
Si se trata de una reescritura 1-a-1, es posible que desee seguir con WinForms, ya que es familiar a lo que tiene. Probablemente necesites utilizar algunos componentes de terceros para poner en marcha tu UI; DevExpress es una buena opción, ya que tienen componentes similares en Delphi y Visual Studio.
Pero si quieres ir por dulces en el futuro, entonces podrías considerar WPF. Prepárese para una curva de aprendizaje más empinada aquí que WinForms ya que es muy diferente de lo que está acostumbrado.
Si decides quedarte con Delphi, es posible que desees consultar VCL para la Web (también conocido como IntraWeb) y para Delphi 2009 (mucho ha cambiado en el mundo Delphi desde que se anunció Delphi 7 hace 6 años).
Buena suerte haciendo sus elecciones!
--jeroen
Sugeriría mirar a Hydra desde RemObjects. Básicamente rapea la interfaz com para usted y proporciona un patrón de observador para la interfaz entre su aplicación Delphi y .Net. Puede hacer que los formularios .Net aparezcan en los paneles dentro de su aplicación Delphi. Esto proporciona una buena ruta de migración en la que reemplaza su código Delphi poco a poco a medida que migra la funcionalidad a .Net.
Trabajé en una empresa que estaba migrando de Delphi a WPF / .Net alrededor de 2007. Probamos un enfoque pieza por pieza. Fue doloroso. Siempre nos encontramos con errores sutiles en la interoperabilidad. Llamar desde Delphi a WPF o Winforms y viceversa es doloroso. Si los diversos controles de la interfaz de usuario y las ventanas de su aplicación se convocan mucho entre sí, creo que experimentará importantes dolores de crecimiento.
Si puede permitirse hacer toda la conversión de inmediato, lo conseguiría. De lo contrario, divida las partes de su aplicación que son independientes o tienen el mínimo de interacciones con el resto de la aplicación.
También sugiero saltar a .Net 2008. ¿Por qué escoges una tecnología que tiene casi 4 años (VS 2005)? Creo que tomar una decisión comercial muy, muy mala es optar por .Net 2.0 cuando .Net 3.5 es muy estable. La única razón válida que alguna vez presentaría a la administración de .Net 2.0 sería que sea compatible con Windows 2000. ¿Todavía tiene clientes en Win2k? ¿Todavía tendrá clientes en Win2k cuando se complete su conversión? ¿Tiene clientes a los que no puede trasladarse a XP o Vista? .Net 3.0 y 3.5 no son compatibles con Win2k. Esa es la única desventaja que puedo pensar.
.Net 3.5 y C # 2008 ofrecen ventajas significativas para su empresa. Tiene una serie de funciones de lenguaje que acelerarán el desarrollo en comparación con C # 2.0. Tienes WPF, que es muy superior a Winforms. Yo diría que puede desarrollar el mismo Windows gris de batería que obtendría en Winforms con WPF, desarrollarlo más rápido, y cuando quiera algo llamativo, usará una tecnología que puede proporcionarlo fácilmente. Si está aprendiendo una nueva plataforma de ventanas para esta conversión, ¿por qué no invertir en aprender cosas nuevas?
Además, dígame que en realidad no compró VS 2005. Puede comprar una licencia de MSDN Universal por aproximadamente el mismo costo y obtener todos los productos relacionados con el desarrollo que Microsoft hace. Cómprelo a un tercero y obtendrá un buen descuento.
Lo siento si salí negativo. Atentamente, buena suerte en la migración. Acabo de tener flashbacks cuando pienso en tener que renunciar a todas las cosas buenas en .Net 3.5.
Ha habido un informe científico de una transformación exitosa de un Proyecto Delphi de 1,5 millones de líneas a C # por John Brant, Don Roberts et al. Escribió un analizador Delphi, un generador de C # y muchas reglas de transformación en el AST. Gradualmente extendiendo el conjunto de reglas, haciendo una compilación diaria, muchas pruebas de unidades y algunas reescrituras de partes difíciles de Delphi le permitieron tener un equipo de 4, entre los cuales algunos de los desarrolladores originales, con profundo conocimiento de Delphi & C #, para migrar el software en 18 meses. John Brant y Don Roberts son los desarrolladores originales del navegador de refactorización y el kit de construcción del compilador SmaCC, es poco probable que puedas ir tan rápido.
Aunque esta fue una inversión significativa, no está en ninguna parte "del mismo tamaño que el desarrollo original". Los autores señalan que una reescritura directa, sin herramientas o con una herramienta de un solo disparo, como señaló Jeroen, es muy probable que resulte en eso, especialmente si se tienen en cuenta nuevos requisitos.
Los autores han realizado refactorizaciones a gran escala mientras permanecían en la misma plataforma para un proyecto diferente, reemplazando por completo la infraestructura de persistencia. Esto podría ser relevante para proyectos antiguos (BDE?).
Anteriormente trabajé en una empresa que quería convertir de Delphi a C # .NET porque .NET es genial y brillante . Trajeron algunos desarrolladores más que tenían mucha experiencia en C # y terminaron teniendo 3 veces más tiempo para que los desarrolladores transfirieran la aplicación a C # y luego escribieron la primera vez en Delphi con muy poco ROI adicional (unos pocos nuevas características fueron agregadas en el proceso). Además, los clientes no estaban contentos con el rendimiento de la aplicación o la interfaz de usuario.
El estudio de caso después del estudio de caso muestra que reescribir es una mala idea . (Sombrero de punta a kogus )
Si debe mudarse a .NET (sí, lo sé, no tomó la decisión, alguien con menos información lo hizo), entonces le sugiero que use Delphi para .NET o RemObjects Oxygene . Este último es un complemento de Visual Studio. Pero incluso marc hofman, el arquitecto jefe de software de RemObjects Oxygene ha dicho que es una mala idea migrar una aplicación perfectamente funcional a .NET "solo porque".
Si puede esperar a Delphi Prism, que también es un complemento de Visual Studio y se espera que salga a finales de este año.