VB.NET tiene el espacio de nombres "mi", pero ¿cuántos desarrolladores de VB.NET realmente lo usan?¿Utiliza el espacio de nombres 'Mi' en VB.NET?
Estoy considerando construir un framework para VB.NET, y usar My namespace para conectarlo a VB parece una idea razonable. ¿Lo es?
El propósito de Mi, según tengo entendido, es ser un atajo fácil para ciertas tareas API que son comunes pero difíciles de encontrar o difíciles de usar. Es probable que no deba incluir por completo su marco en Mi. (Por un lado, las personas C# que usan su marco de trabajo pueden ponerse de mal humor.)
En su lugar, debe diseñarlo como un marco normal. Cuando hayas terminado, haz una lista de algunas tareas comunes para las cuales la gente podría querer usar tu marco. Vea si alguno de estos podría ser útil tener en Mi, especialmente cuando hay clases o métodos que se pueden usar de varias maneras, pero tienen uno o dos usos realmente comunes que se pueden abreviar con Mi.
En este artículo se muestra cómo extender mi, y tiene una sección al final que describe algunas pautas de diseño a seguir: Simplify Common Tasks by Customizing the My Namespace
cuanto a su pregunta principal, al codificar en VB .NET, utilizo mi tan a menudo como puedo. Reduce una cantidad de operaciones a una línea de código.
Uso principalmente C# y Boo, pero cuando uso VB.NET utilizo My namespace con bastante frecuencia. No veo ninguna razón para no simplificar la codificación. Todavía conserva su legibilidad.
Solo lo he usado desde la perspectiva del usuario, nunca he enchufado nada en él. Considero que el espacio de nombres Mi es un mecanismo de ayuda global altamente confiable, provisto por plataformas. Atajos oficialmente sancionados, de verdad. Me podría sorprender ver código de usuario externo o de terceros allí.
Como tal, recomendaría que vb framework defina su propio espacio de nombres apropiadamente nombrado en lugar de engancharse al espacio de nombres Mi existente. Tal marco no debería tener ese sentimiento "global".
Me gusta mucho el espacio de nombres "Mi" en VB.NET y siempre lo uso en mis aplicaciones de WindowsForms, porque es muy intuitivo.
utilizo principalmente estas categorías:
Creo que, si sus extensiones para mi de su marco se ajustan bien, a continuación, muchos programadores de VB.NET se apreciarlos.
Nunca lo he usado hasta ahora, aunque en realidad nunca lo investigué.
No aconsejaría poner nada en el espacio de nombres Mi mismo, es mucho más claro simplemente exponerlo como lo haría si fuera un marco sin VB.
Lo usamos en algún código, pero con cierta vacilación. Es cierto que My a menudo ayuda a que el código sea más legible. Por ejemplo, la enumeración Environment.SpecialFolder curiosamente carece de un miembro Temp, mientras que My.Computer.FileSystem.SpecialDirectories tiene una (Path.GetTempPath() también, pero no es intuitiva en comparación con otras carpetas especiales).
Pero My solo es beneficioso en tales casos porque las API existentes están mal diseñadas, no porque My es inherentemente mejor. Al igual que JAGregory, sugiero que se evite la extensión de My, o cualquier otro tipo de espacio de nombre global, variable, etc., siempre que sea posible. La idea simplemente no se ajusta a una arquitectura OOP limpia.
Se podría argumentar que está valorando una arquitectura OOP limpia antes de la productividad y la legibilidad? – MarkJ
Nunca uso My namespace (soy desarrollador de C#), pero mi compañero de trabajo de VB no lo hace.Encontré que los miembros de My no son necesarios porque, en muchos casos, son contraintuitivos para mí, p. en mi opinión, abrir un archivo tiene algo que ver con IO (de ahí System.IO.File) y no con mi computadora (My.Computer.FileSystem). Siempre parecen tan dispersos y agrupados juntos.
Es solo un relanzamiento de la funcionalidad que ya está disponible, de lo contrario, en todos los idiomas. Y no me gusta depender de Microsoft.VisualBasic.dll cuando estoy desarrollando .NET. Siempre prefiero System. *.
Y luego, siempre es un poco limitado. Veo que los desarrolladores de VB tienen problemas con su aplicación cuando no pueden encontrar algo en el espacio de nombres Mi, porque no pueden imaginarse que pueda usar algo en el espacio de nombres del Sistema. Eso, por supuesto, no es un problema del My namespace en sí mismo.
Love the My! Cualquier cosa que me ayude a hacer el trabajo más rápido, y proporciona código para soluciones que no tengo que escribir, ¡mejor!
No lo uso mucho.
Estoy considerando construir un framework para VB.NET, y usar My namespace para conectarlo a VB parece una idea razonable. ¿Lo es?
Si cabe, por supuesto, úselo. Como no ofreció más información sobre su marco, es difícil de decir. No pondría cosas de propósito general en el espacio de nombres My (como las cosas de My.Computer) porque realmente no hay ninguna ventaja al ponerlo allí. Sin embargo, los ayudantes centrados en la aplicación encajan bien.
He usado Mi en mis proyectos de VB.NET, y no me siento culpable por ello. Soy principalmente un chico de C#, pero hasta que cambié mi compañía a C#, éramos una tienda de VB. En mi opinión, My namespace es una buena pieza de azúcar sintáctica. Así como no estoy avergonzado de usar el operador de coalescencia de C# y otro azúcar, tampoco me da vergüenza usar el azúcar de VB. (Hasta cierto punto, no usaré las funciones VB clásicas que .NET aún expone.)
Dicho esto, nunca ponga nada en ese espacio de nombres. Es el espacio de nombres de Microsoft, y del mismo modo que no pondría nada en el sistema ni en Microsoft, no coloque nada debajo de Mi. Causará confusión más adelante, si no fuera por usted, luego por otros que mantienen su código. Crea tu propio espacio de nombres para tu propio código.
+1 para "no extender mi". Eso definitivamente confundirá a los mantenedores. ¿Y qué sucede cuando sale VB2015, y Microsoft ha agregado algo a Mi que entra en conflicto con lo que ha agregado? – MarkJ
Uso My.Settings y My.Computer a menudo durante la programación en VB.NET. Disfruto particularmente de My.Settings como alternativa al uso de ConfigurationManager.AppSettings cuando es apropiado.
Estoy de acuerdo con John Rudy sobre el uso de My. Es el azúcar sintáctico que hace la vida un poco más legible.
También puede usarlo desde C#, aunque no muchos desarrolladores de C# parecen usarlo. –
aquí está el enlace para los interesados: http://msdn.microsoft.com/en-us/library/ms173136.aspx –