Desarrollador de Delphi cambiando a C#

Question

Soy Delphiholic desde hace bastante tiempo y últimamente estaba pensando en aprender algo de C# también, sin embargo estoy un poco "temeroso de lo desconocido", he hecho algunas aplicaciones simples como una prueba de manejo para C# y tengo que admitir que me ha gustado, SIN EMBARGO, realmente no me gusta el IDE ... una vez dicho esto, esta es la pregunta que agradecería si otros que siguieron este camino respondieran:

Como desarrollador de Delphi, ¿cuáles son los "principales cambios básicos" del lenguaje Delphi (por básico me refiero a funciones básicas de utilidad, transmisiones, etc.), estoy acostumbrado a agregar "Sistema, Clases, Windows" a no usa "use System.XXX.YYY.ZZZ", estoy tratando de hacer una igualdad parcial en mi mente desde Delphi hasta C# hasta que pueda ver de dónde viene Delphi de la mano con C# y así sucesivamente ...

espero que la pregunta es bastante claro, si no, no dude en jurar y voy a tratar de aclarar tan bien como yo :-)

Answer 1

Utilizo mucho para el desarrollo de software.

La velocidad de desarrollo de las aplicaciones de servidor (aplicaciones web, servicios web, servicios de Windows) es mucho más alta en .NET.

La velocidad de desarrollo de las aplicaciones de negocio (interfaz de usuario pura de Windows) es mucho mayor en Delphi.

El desarrollo de aplicaciones sexys es un problema en ambos entornos.

Algunas cosas que debe saber:

• aprendizaje del marco .NET tomará mucho tiempo: es enorme, pero contiene una gran cantidad de artilugios (algunas joyas están muy bien escondidos).
• No se pierda al seguir todas las nuevas tendencias a la vez: genéricos, lambda, LINQ, cada uno es bueno, pero captarlos todos a la vez es solo para unos pocos
• Para aplicaciones web, omita WebForms, pero aprender ASP.NET MVVC (sí, los chicos de Ruby tenían razón después de todo); aprende HTML 5 y JavaScript también.
• Para aplicaciones de Windows atractivas, aprenda WPF, pero prepárese para una curva de aprendizaje empinada (el diseñador y el marco son radicalmente diferentes)
• No obtenga una interfaz de usuario demasiado sexy: le costará una cantidad desproporcionada de tiempo mientras los usuarios esperan la funcionalidad
• Como el mercado ha estado atacando a Delphi desde la versión 1, the market is bashing SilverLight too
• Saltar WinForms; si necesita algo como WinForms, entonces Delphi es mucho más productivo (más aún si tiene una base de código Delphi VCL existente).
• WPF es tan fácil de usar como VCL o WinForms (léase: ninguno de los 3 es compatible con subprocesos)
• No realice reescrituras de sus cosas Delphi en .NET (o para el caso de cualquier otro 1: 1 reescribo desde la plataforma A a la plataforma B): es una pérdida de tiempo.
• Enlazar y sincronizar son un problema en todos los entornos de desarrollo. El problema no es tanto en lo general (el Concurrent Collections en .NET 4 framework ayuda, como lo hace en el Delphi OmniThreadLibrary), pero para obtener los detalles finales y los casos de excepción correctos es el verdadero dolor.
• La recolección de basura no significa que no se pierda la memoria: significa que no se filtrará cuando termine la aplicación, pero mientras se ejecuta las fugas son mucho más difíciles de detectar (chico, desearía tener la memoria FastMM monitor para .NET)

--jeroen

Answer 2

Los "principales" cambios básicos son que de .NET la biblioteca está orientada a objetos. Por ejemplo, en lugar de funciones de cadena globales que se distribuyen entre System, SysUtils, StringUtils, etc., todas son solo métodos estáticos en la clase String. En lugar de las funciones globales de manipulación de rutas, son métodos estáticos en la clase Path o en la clase File. En lugar de TextFile/AssignFile/Rewrite, crea un StreamReader (o simplemente llame al File.ReadAllLines estático o ReadAllText si el archivo es pequeño). La mayoría de las cosas son bastante reconocibles con un poco de hurgar. Faltan algunas cosas; por ejemplo, no existe un método IncludeTrailingPathDelimiter en .NET (aunque generalmente no lo necesita, Path.Combine es mejor).

Voy a en segundo lugar la sugerencia de omitir WinForms. Si ha utilizado el Delphi VCL, WinForms será familiar y, sin embargo, frustrante, enloquecedor, inadecuado. Tomaron las ideas básicas de la VCL pero nunca se molestaron en darle la más mínima profundidad, o incluso usabilidad. No hay equivalente para TAction/TActionList, la propiedad Dock (equivalente a Delphi's Align) le gusta ocultar los controles uno detrás del otro hasta que juegues con "Bring to Front"/"Send to Back", los tooltips requieren un componente adicional en tu formulario. solo hay un puñado de controles, y eso está fuera de mi cabeza. Tómese el tiempo para aprender WPF; tiene toda la riqueza de la VCL y más, y hará que gastes mucho menos tiempo golpeándote la cabeza contra la pared.

El IDE toma un tiempo para acostumbrarse, pero me gusta mucho mejor que Delphi. Tienes que aprender un conjunto diferente de teclas, pero eso no es gran cosa. El IDE es más receptivo (nada de eso se bloquea durante la compilación de "fondo"). También tiene algunos complementos kick-ass: después de haber usado ReSharper por un tiempo, no perderá un poco el Delphi IDE.