Для чего мне использовать пространство имен My в VB .NET?

Цель My, насколько я понимаю, состоит в том, чтобы быть простым ярлыком для определенных задач API, которые являются общими, но труднодоступными или трудными в использовании. Вы, вероятно, не должны полностью включать свою структуру в My. (Во-первых, пользователи C#, использующие ваш фреймворк, могут стать ворчливыми.)

Вместо этого вы должны разработать его как обычный фреймворк. Когда вы закончите, составьте список некоторых общих задач, для которых люди могут захотеть использовать вашу платформу. Посмотрите, может быть полезно иметь какой-либо из них в My, особенно там, где есть классы или методы, которые можно использовать несколькими способами, но у них есть одно или два действительно распространенных использования, которые можно сократить с помощью My.

В этой статье показано, как расширить My, а в конце есть раздел с описанием нескольких рекомендаций по проектированию, которым необходимо следовать: Упростите общие задачи, настроив мое пространство имен

Что касается вашего основного вопроса, при кодировании в VB .NET я использую My так часто, как могу. Это сокращает количество операций до одной строки кода.

Мне очень нравится пространство имен My в VB.NET, и я всегда использую его в своих приложениях WindowsForms, потому что оно интуитивно понятно.

Я использую в основном эти категории:

• My.Computer: в первую очередь для файловой системы и сети.
• My.Application: номер версии, текущий каталог
• My.Resources: доступ к ресурсам, используемым приложением, находящимся в файлах ресурсов строго типизированным образом.
• My.Settings: очень удобно

Я думаю, если ваши расширения для My вашего фреймворка подойдут, то многие программисты VB.NET их оценят.

Я использовал My в своих проектах VB.NET и не чувствую вины за это. В первую очередь я разбираюсь в C#, но пока я не перевел свою компанию на C#, мы были магазином VB. На мой взгляд, пространство имен My — хороший синтаксический сахар. Точно так же, как я не стесняюсь использовать оператор объединения C# и другой сахар, я также не стесняюсь использовать сахар VB. (В какой-то степени я не буду использовать классические функции VB, которые все еще предоставляет .NET.)

Тем не менее, никогда ничего не помещайте в это пространство имен. Это пространство имен Microsoft, и точно так же, как вы ничего не помещаете в System или Microsoft, не помещайте ничего в My. Позже это вызовет путаницу — если не у вас, то у тех, кто поддерживает ваш код. Создайте собственное пространство имен для собственного кода.

Мы используем его в некотором коде, но нерешительно. Это правда, что My часто помогает сделать код более читабельным. Например, в перечислении Environment.SpecialFolder странным образом отсутствует член Temp, тогда как в перечислении My.Computer.FileSystem.SpecialDirectories он есть (Path.GetTempPath() тоже подойдет, но это вряд ли интуитивно понятно по сравнению с другими специальными папками).

Но My полезен в таких случаях только потому, что существующие API плохо спроектированы, а не потому, что My по своей сути лучше. Как и JAGGregory, я настоятельно рекомендую по возможности избегать расширения My — или любого другого вида глобального пространства имен, переменных и т. д. Идея просто не соответствует чистой архитектуре ООП.

Я никогда не использую пространство имен My (я разработчик C#), но мой коллега по VB тоже этого не делает. Я обнаружил, что члены My не нужны, потому что во многих случаях они нелогичны для меня, например. на мой взгляд, открытие файла как-то связано с вводом-выводом (отсюда System.IO.File), а не с моим компьютером (My.Computer.FileSystem). Они всегда кажутся такими рассеянными и собранными вместе.

Это всего лишь некоторая переработка функциональности, которая уже доступна на всех языках. И мне не нравится зависеть от Microsoft.VisualBasic.dll, когда я разрабатываю для .NET — я всегда предпочитаю System.*.

И потом, это всегда как бы ограничено. Я вижу, как разработчики VB борются со своим приложением, когда не могут найти что-то в пространстве имен My, потому что не могут себе представить, что можно использовать что-то в пространстве имен System. Это, конечно, не проблема самого пространства имен My.

В основном я использую C# и Boo, но когда я использую VB.NET, я довольно часто использую пространство имен My. Я не вижу причин не упрощать кодирование. Он по-прежнему сохраняет свою читабельность.

Я использовал его только с точки зрения пользователя, я никогда ничего не подключал к нему. Я считаю пространство имен My очень надежными глобальными вспомогательными механизмами, предоставляемыми платформой. Официально санкционированные ярлыки, правда. Я могу быть удивлен, увидев там внешнего пользователя или сторонний код.

Таким образом, я бы посоветовал фреймворку vb определить собственное пространство имен с соответствующими именами вместо того, чтобы цепляться за существующее пространство имен My. Такой фреймворк не должен иметь такого «глобального» ощущения.

Никогда не использовал его до сих пор, хотя я никогда не изучал его.

Я бы не советовал помещать что-либо в пространство имен My самостоятельно, гораздо понятнее просто разместить его так, как если бы это была не-VB-инфраструктура.

Люблю My! Все, что помогает мне выполнять работу быстрее и предоставляет код для решений, которые мне не нужно писать, тем лучше!

Я часто использую My.Settings и My.Computer при программировании на VB.NET. Мне особенно нравится My.Settings как альтернатива использованию ConfigurationManager.AppSettings, когда это уместно.

Я согласен с Джоном Руди по поводу использования My. Это синтаксический сахар, который делает жизнь немного более читабельной.

Я не использую его много.

Я рассматриваю возможность создания фреймворка для VB.NET, и использование пространства имен My для его подключения к VB кажется разумной идеей. Это?

Если он подходит, во что бы то ни стало, используйте его. Поскольку вы не предоставили никакой дополнительной информации о своей структуре, трудно сказать. Я бы не стал помещать вещи общего назначения в пространство имен My (например, вещи My.Computer), потому что на самом деле нет никакого преимущества в том, чтобы помещать их туда. Тем не менее, помощники, ориентированные на приложения, хорошо вписываются.