martes, marzo 07, 2006

Para aprender .NET

Tenía un comentario sin responder en una entrada que se ha movido al archivo (Open Source Killed the Software Star). La pregunta era, más o menos, cuánto se tardaba en dominar .NET.

Si es para programar en ASP.NET (especialmente, la versión dos), la curva de aprendizaje es muy cómoda. En una semana está usted escribiendo código... siempre que se trate de aplicaciones con poca carga. Esta salvedad la hago pensando en la dificultad adicional de entender cómo funciona a fondo el sistema de acceso a datos en ADO.NET. Pero si se limita a imitar las técnicas más sencillas de acceso a datos, no hay demasiada dificultad. Y en muchas aplicaciones bastará con esto.

¿Es mucho o es poco? En la cuenta he incluido el tiempo necesario para experimentar con la administración de proyectos, y los primeros golpetazos con el lenguaje. Estoy pensando también en un programador con experiencia en Delphi o Java, no en un novato absoluto. Pongo a Java aquí en el mismo nivel que Delphi porque en este caso, el control de eventos es menos complicado.

Donde se puede tardar algo más es en las aplicaciones de interfaz gráfica, especialmente para sistemas divididos en capas. El programador de Delphi tiene aquí una ventaja importante (si conoce DataSnap, por supuesto). La dificultad viene dada porque ADO.NET no ofrece una interfaz similar a IDataBroker para definir el intercambio entre capas. Usted tiene todos los elementos para construir el sistema que le apetezca, y los bloques modulares son muy potentes y a la vez sencillos... pero depende de usted la forma que vaya a adoptar ese sistema. Por experiencia, cuando uno aprende un sistema nuevo, esta riqueza de alternativas suele percibirse más bien como una "amenaza": existe el temor fundado de elegir la vía menos apropiada y pagarlo a la larga.

En esto, la ayuda que puedo ofrecerle es el curso de ADO.NET. Precisamente, el objetivo de este curso es montar un sistema de este tipo, primero para el acceso a datos, y luego para la propia estructura de la aplicación (ventanas, menús, etc).

Respecto a la posibilidad de atascarse por culpa de un hueco de funcionalidad, las probabilidades son mínimas. En primer lugar, .NET v2.0 ha añadido un buen puñado de APIs para resolver problemas de este tipo: cifrado, compresión, etc. Pero sobre todo, siempre existe la posibilidad de acceder a una función ubicada en una DLL nativa, o simplemente importar una clase ActiveX para manejarla como si se tratase de una clase nativa .NET. Este procedimiento debe ser siempre la última opción, por supuesto... pero es bueno saber que está ahí, y que es fácil de utilizar.

Para quien no la conozca, exista una página, PInvoke.NET, que contiene prototipos para la mayoría de las funciones nativas del API de Windows (¡visite la sección Helpful tools!). Se trata de un "wiki", por lo que la página está en constante crecimiento. Por supuesto, siempre queda el problema de saber qué hacer con la función del API... pero se supone que estamos hablando de una persona que ya sabía cómo desenvolverse con Delphi y que ahora quiere probar fuerzas en .NET.

1 Comments:

Anonymous Anónimo said...

Hola,
a mí lo que más me está costando del ASP .Net es todo el tema de saber qué va en ejecución del cliente, qué en el servidor, la persistencia de los objetos y temas así. Mi escusa es que desde Delphi 1 hice programación para Windows y no para web. Al reciclaje me mandaron.

Por otro lado, en ambos cursitos de iniciación al .Net que hice, que realicé junto a anteriores usuarios de Visual Studio, tanto programadores de VB6 como de ASP, me pareció que tenían más dificultades en entender conceptos que yo ya traía asimilados de Delphi que los compañeros que veníamos de otras tecnologías.

Un enlace con multitud de artículos para aprender .net:
http://www.willydev.net/

Saludos

miércoles, marzo 08, 2006 10:07:00 a. m.  

Publicar un comentario

<< Home