2008-10-28 6 views
6

Estoy preparando una clase en Visual Basic 2005 dirigida a programadores de Visual Basic 6 que migran a la plataforma .NET.Funciones de tiempo de ejecución de VB en VB.NET para programadores VB6

Mi principal preocupación es enseñar a mis alumnos las mejores prácticas para desarrollar en .NET, y me pregunto si considero que el uso de las funciones de tiempo de ejecución de VB.NET es legítimo o no.

He leído que muchas de las funciones de VB en VB.NET realmente invocan métodos en .NET Framework, por lo que parece que existen principalmente para facilitar la transición de versiones anteriores de Visual Basic a VB.NET. Sin embargo, the VB.NET team parece recomendar su uso siempre que sea posible, ya que afirman que ponen algunas optimizaciones en la parte superior de las API de .NET Framework.

¿Cuál es su opinión sobre esto?

+1

Ver también [este debate] (http://stackoverflow.com/questions/226517/is-the-microsoft-visualbasic-namespace-true-net-code) – MarkJ

Respuesta

7

Donde estoy, tengo que ir y venir entre C# y VB.Net con frecuencia. Con esto en mente, realmente no nos gustan las viejas funciones de VB, especialmente las funciones de cadenas: Trim(), Replace(), Len(), UCase(), etc. Parecen extrañas en un programa .Net, y no me gustaría verlas en el código. Tenía que trabajar en.

La única excepción podría ser Len(), si lee el código en su cabeza con el of verbage. En ese caso, leer Len(theString) como length of theString parece tener sentido. En los demás, es más una operación realizada por la cadena, y entonces quiero ver el. (punto) notación.

Por otro lado, he tenido un tiempo difícil destete a mí mismo de los operadores de conversión: CStr, CInt, CDbl, etc.

No se por qué me gusta un tipo y no el otro lo sé; podría ser que encuentre Convert.To ___() demasiado detallado, o tal vez tenga algo que ver con que sean operadores en lugar de funciones.

Editar
Este punto algo se perdió en el resto de mi post, así que quiero destacar una vez más:

En muchos lugares, VB.Net coexiste con C#. No creo que veas tantas tiendas VB.Net como puedas para C#. Simplemente no es tan popular, y muchas de las tiendas de VB.Net se mueven a VB.Net solo como un estado de transición, mientras que los programadores también aprenden C#.En estos entornos mixtos, tiene mucho sentido si las funciones antiguas de VB están estrictamente prohibidas en el nuevo código. Nunca se sabe cuándo se tendrá que mover un módulo, y hay algunos gastos indirectos para compartir los dos estilos a la vez. Entonces, realmente es una mala idea no entender ambos.

+2

No estoy seguro exactamente a qué se refiere al decir que VB.NET es "menos popular", pero Lisa Feigenbaum, una PM de Microsoft en el Grupo de Idiomas Administrados .NET, dice que actualmente hay un poco más de desarrolladores de VB.NET que C#. http://www.infoq.com/news/2009/06/Future-VB.NET – MarkJ

+0

(¡Por cierto, te di +1!) Otro desacuerdo menor. Creo que te ayuda a evitar el error clásico de "cadena inmutable" si usas Reemplazar (s, "a", "b") en lugar de s.Reemplazar ("a", "b"). Por ejemplo, el error cometido por sholsinger aquí http://stackoverflow.com/questions/1112553/why-cant-i-do-string-replace-on-a-io-file-readalltext-string – MarkJ

+2

Escucha, escucha, votaría esto hasta cien veces si pudiera! He visto el código más horrendo producido por los desarrolladores que piensan que pueden salirse con la suya sin aprender VB.NET porque su código VB6 funciona. –

-3

Si está enseñando VB, esas funciones son parte de VB. Si está enseñando .Net Framework, esas funciones no son parte del Framework. Si intenta hacer su trabajo y tiene herramientas disponibles, use sus herramientas.

+3

En realidad, _es_parte_ del marco. Incluso puede usarlos desde C# si lo desea. –

4

Bueno, supongo que debes tomarlos al pie de la letra. Soy un programador de C# principalmente, pero he estado trabajando en una aplicación web VB.NET durante las últimas 6-8 semanas.

La estimación de mi asiento de los pantalones sugiere que el uso de funciones de conversión como CInt, CDate, etc. sea tan rápido como usar métodos Convert.Toxxx.

Mi consejo sería: si lo hace más fácil, y no tiene una penalización de rendimiento, ¡adelante! También les enseñaría el enfoque .NET y dejaría que el usuario decida.

BTW, como un chico C#, me encanta la facilidad de las rutinas Cxxx. El hecho de que solo estén disponibles en VB.NET no significa que no deba usarlos (en mi humilde opinión). Caballos para cursos y todo eso.

+2

Agregue una directiva using para Microsoft.VisualBasic y también puede usarla desde C#. –

3

Si desea enseñar las mejores prácticas de .Net framework que se pueden mover hacia adelante y hacia atrás entre los idiomas, le sugiero que elimine la importación global para Microsoft.VisualBasic. Esto esencialmente te obliga a hacer un Microsoft.VisualBasic.Trim() etc. en lugar de solo "Trim()".

Si no me equivoco, en Visual Studio 2008 ahora tiene la capacidad de eliminar la referencia todos juntos para el modo "puro" .Net en vb.net, lo que hace que sea más fácil moverse entre los idiomas.

Si solo está enseñando vb.net chicos, como los carteles mencionados anteriormente, utilícelos, ya que están disponibles y requieren menos tipeo.

4

Ya hay mucho que los programadores de VB6 pueden aprender para pasar a VB.NET. Por qué no dejarlos usar las funciones VB al principio, pero sí enseñarles las versiones .NET framework. Más tarde, podrían cambiar a las funciones de .NET Framework, especialmente si es probable que también necesiten usar C#.

EDITAR (mucho más tarde): ¡dos renombrados gurús de VB toman vistas opuestas!

  • Francesco Balena (en su popular libro Programming Microsoft Visual Basic 2005: The Language) recomienda a los desarrolladores ex VB6 aprender la sintaxis .NET tan pronto como se sienten cómodos con el nuevo idioma y evitar el uso de métodos y clases en Microsoft.VisualBasic espacio de nombres si es posible [p . 100]. Su punto es que, en general, los métodos .NET nativos ofrecen una mayor flexibilidad y su aprendizaje es una inversión en caso de que luego necesite usar C# u otro lenguaje .NET.
  • Dan Appleman (en su popular libro Moving to VB.NET: Strategies, Concepts, and Code) recomienda que se sienten libres para seguir con el espacio de nombres Microsoft.VisualBasic nativa solamente evitando aquellos en el espacio de nombres Microsoft.VisualBasic.Compatibility.VB6 [p. 265]. Su punto es que Microsoft.VisualBasic es una parte central del framework .NET.
+0

Gracias por destacar esos dos libros, muy interesante. –

+2

Vale la pena leerlos si eres un programador de VB6 que se mueve tarde a .NET. (Por ejemplo, me gusta, erm, yo!) Algunos de los contenidos de Dan Appleman no son correctos para las últimas versiones de frameworks, pero es tan bueno para explicar los resúmenes que aún vale la pena leerlos. – MarkJ

+1

Gran comentario, y el punto de Dan Appleman es muy bueno. Es probable que el espacio de nombres + Compatibilidad + no se mantenga a menos que tengas muy buenas razones para ello. El espacio de nombres MS.VisualBasic, OTOH, es perfectamente razonable de utilizar desde Iron Python, C# etc. Es parte del Core, y algunas de las funciones que hay allí son bastante prácticas. – DarinH

2

Una cosa que probablemente deberías mencionar si mencionas los métodos de framework y las funciones de VB.NET es que, aunque a veces parezcan iguales, en realidad pueden hacer sutilmente cosas diferentes.

Por ejemplo, el operador de igualdad para las cadenas trata una cadena nula como el mismo que String.Empty (ver The real cost of performance para un ejemplo de lo que sucede cuando se le olvida!)

Además, las funciones de VB.NET a menudo dan una buena configuración predeterminada para realizar la operación en cuestión, pero donde necesita más control, a menudo será necesario volver a los métodos de Framework, por ejemplo, si necesita make string conversions in a different culture.

Cuestiones relacionadas