VB.NET имеет "мое" пространство имен, но сколько VB.NET-разработчиков действительно используют его?
Я рассматриваю возможность создания фреймворка для VB.NET, и использование пространства имен My, чтобы подключить его к VB, кажется разумной идеей. Это?
Цель My, как я понимаю, - быть простым ярлыком для некоторых задач API, которые являются общими, но труднодоступными или труднодоступными. Вероятно, вы не должны полностью использовать свою инфраструктуру под My. (Во-первых, люди С#, использующие вашу фреймворку, могут быть втянуты.)
Вместо этого вы должны создать его как обычную структуру. Когда вы закончите, создайте список некоторых общих задач, для которых люди могут использовать вашу инфраструктуру. Посмотрите, может ли быть полезно любое из них в разделе "Мой", особенно в тех случаях, когда есть классы или методы, которые можно использовать несколькими способами, но у них есть одно или два действительно распространенных способа использования, которые могут быть сокращены с помощью My.
В этой статье показано, как расширить My, и в конце он содержит раздел, который описывает несколько руководств по дизайну: Упростить общие задачи, настроив My Пространство имен
Что касается вашего основного вопроса, при кодировании в VB.NET я использую My как можно чаще. Он уменьшает количество операций до одной строки кода.
Мне очень нравится "Мое" пространство имен в VB.NET, и я всегда использую его в своих приложениях WindowsForms, потому что он очень интуитивно понятен.
Я использую в основном эти категории:
Я думаю, что если ваши расширения для My из вашей фреймворка подходят хорошо, тогда многие программисты VB.NET оценят их.
Мы используем его в некотором коде, но нерешительно. Это правда, что My часто помогает сделать код более читаемым. Например, перечисление Environment.SpecialFolder любопытно лишено члена Temp, тогда как My.Computer.FileSystem.SpecialDirectories имеет один (Path.GetTempPath() будет делать то же самое, но вряд ли интуитивно по сравнению с другими специальными папками).
Но My полезен только в таких случаях, потому что существующие API-интерфейсы плохо разработаны, а не потому, что My по своей сути лучше. Как и JAGregory, я настоятельно рекомендую избегать расширения My или любого другого глобального пространства имен, переменных и т.д., Когда это возможно. Идея просто не соответствует чистой архитектуре ООП.
Я использовал My в моих проектах VB.NET, и я не чувствую себя виноватым в этом. Я в первую очередь парень из С#, но пока я не перешел на С#, мы были магазином VB. На мой взгляд, пространство имен My - это хороший кусок синтаксического сахара. Так же, как я не стесняюсь использовать С# coalesce оператора и другого сахара, я не стесняюсь использовать VB сахара. (В какой-то степени я не буду использовать классические функции VB, которые все еще предоставляет .NET.)
Тем не менее, никогда не помещает ничего в это пространство имен. Это пространство имен Microsoft, и так же, как вы ничего не ставите в Системе или Microsoft, не ставьте ничего под My. Это вызовет путаницу позже - если не для вас, то для других, которые поддерживают ваш код. Создайте собственное пространство имен для своего собственного кода.
Я никогда не использую пространство имен My (я разработчик С#), но мой сотрудник VB не работает. Я обнаружил, что мои члены не нужны, потому что во многих случаях они противоречат интуиции для меня, например. на мой взгляд, открытие файла имеет какое-то отношение к IO (следовательно, System.IO.File), а не к моему компьютеру (My.Computer.FileSystem). Они всегда кажутся такими разбросанными и сгруппированными вместе.
Это просто некоторый набор функций, который уже доступен в других версиях, со всех языков. И мне не нравится в зависимости от Microsoft.VisualBasic.dll, когда я разрабатываю .NET. Я всегда предпочитаю System. *.
И тогда это всегда будет ограниченным. Я вижу, что разработчики VB работают со своим приложением, когда они не могут найти что-то в пространстве имен My, потому что они не могут себе представить, что вы можете использовать что-то в пространстве имен System. Это, конечно, не проблема самого пространства имен My.
В основном я использую С# и Boo, но когда я использую VB.NET, я часто использую пространство имен My. Я не вижу причин, чтобы не упрощать кодирование. Он по-прежнему сохраняет читаемость.
Я использовал его только с точки зрения пользователя, я никогда ничего не подключал к нему. Я считаю, что пространство имен My является некоторыми высоконадежными, обеспечиваемыми платформой, глобальными вспомогательными механизмами. Официально санкционированные ярлыки, действительно. Я был бы удивлен, увидев там внешний пользователь или сторонний код.
Как таковой, я бы рекомендовал инфраструктуре vb определить собственное собственное пространство имен имен, а не привязываться к существующему пространству имен My. Такая структура не должна обладать этим "глобальным" чувством.
Никогда не использовал его до сих пор, хотя я никогда не рассматривал его также.
Я бы не советовал помещать что-либо в пространство имен My самостоятельно, гораздо более ясно, как просто выложить его так, как если бы это была рамка, отличная от VB.
Люби меня! Все, что помогает мне быстрее выполнять работу и предоставляет код для решений, которые мне не нужно писать, тем лучше!
Я часто использую My.Settings и My.Computer во время программирования на VB.NET. Мне особенно нравится My.Settings как альтернатива использованию ConfigurationManager.AppSettings, когда это уместно.
Я согласен с Джоном Руди в использовании My. Это синтаксический сахар, который делает жизнь более читаемой.
Я не использую его много.
Я рассматриваю возможность создания фреймворка для VB.NET, и использование пространства имен My, чтобы подключить его к VB, кажется разумной идеей. Это?
Если он подходит, непременно используйте его. Поскольку вы не предлагали никакой дополнительной информации о своей структуре, трудно сказать. Я бы не помещал вещи общего назначения в пространство имен My (например, материал My.Computer), потому что на самом деле нет никакого преимущества для его размещения. Однако помощники, ориентированные на приложения, хорошо вписываются.