Вы используете пространство имен My в VB.NET?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не часто им пользуюсь.

I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?

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

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

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

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

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

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

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

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

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