VB.NET имеет «мое» пространство имен, но сколько VB.NET-разработчиков действительно используют его?Используете ли вы пространство имен «My» в VB.NET?
Я рассматриваю возможность создания рамки для VB.NET и использование пространства имен My, чтобы подключить ее к VB, кажется разумной идеей. Это?
Цель My, как я понимаю, - быть простым ярлыком для некоторых задач API, которые являются общими, но труднодоступными или труднодоступными. Вероятно, вы не должны полностью использовать свою инфраструктуру под My. (Во-первых, люди C#, использующие вашу инфраструктуру, могут получить ворчание.)
Вместо этого вы должны спроектировать его как обычный каркас. Когда вы закончите, создайте список некоторых общих задач, для которых люди могут использовать вашу инфраструктуру. Посмотрите, может ли быть полезно любое из них в разделе «Мой», особенно там, где есть классы или методы, которые можно использовать несколькими способами, но у них есть одно или два действительно распространенных способа использования, которые могут быть сокращены с помощью My.
В этой статье показано, как продлить мой, и он имеет раздел в конце, который описывает несколько руководящих принципов проектирования, чтобы следовать: Simplify Common Tasks by Customizing the My Namespace
Как ваш главный вопрос, при кодировании в VB .NET, я использую My как можно чаще. Он уменьшает количество операций до одной строки кода.
В основном я использую C# и Boo, но когда я использую VB.NET, я часто использую пространство имен My. Я не вижу причин, чтобы не упрощать кодирование. Он по-прежнему сохраняет читаемость.
Я использовал его только с точки зрения пользователя, я никогда ничего не подключал к нему. Я считаю, что пространство имен My является некоторыми высоконадежными, обеспечиваемыми платформой, глобальными вспомогательными механизмами. Официально санкционированные ярлыки, действительно. Я был бы удивлен, увидев там внешний пользователь или сторонний код.
Как таковой, я бы посоветовал инфраструктуре vb определить собственное собственное пространство имен имен, вместо того, чтобы защелкиваться в существующем пространстве имен My. Такая структура не должна иметь этого «глобального» чувства к ней.
Мне очень нравится «мое» пространство имен в VB.NET, и я всегда использую его в своих приложениях WindowsForms, потому что он очень интуитивно понятен.
Я использую в основном эти категории:
Я думаю, если ваши расширения для My вашей структуры хорошо подходят, то многие программисты VB.NET бы оценить их.
Никогда не использовал его до сих пор, хотя я и вправду никогда не изучал его.
Я бы не советовал вкладывать что-либо в пространство имен My самостоятельно, гораздо более ясно, как это сделать, как если бы это была рамка, отличная от VB.
Мы используем его в некотором коде, но нерешительно. Это правда, что My часто помогает сделать код более читаемым. Например, в перечислении Environment.SpecialFolder любопытно отсутствует член Temp, тогда как My.Computer.FileSystem.SpecialDirectories имеет один (Path.GetTempPath()), но вряд ли интуитивно по сравнению с другими специальными папками).
Но My полезен только в таких случаях, поскольку существующие API-интерфейсы плохо разработаны, а не потому, что My по своей сути лучше. Как и JAGregory, я настоятельно рекомендую избегать расширения My - или любого другого глобального пространства имен, переменных и т. Д. - когда это возможно. Идея просто не соответствует чистой архитектуре ООП.
Можно ли утверждать, что вы оцениваете чистую архитектуру ООП, прежде чем производительность и удобочитаемость? – MarkJ 2009-10-16 11:42:48
Я никогда не использую пространство имен My (я разработчик C#), но мой коллега VB не так хорошо.Я обнаружил, что мои члены не нужны, потому что во многих случаях они противоречат интуиции для меня, например. на мой взгляд, открытие файла имеет какое-то отношение к IO (следовательно, System.IO.File), а не к моему компьютеру (My.Computer.FileSystem). Они всегда кажутся такими разбросанными и сгруппированными вместе.
Это всего лишь несколько новых функций, которые уже доступны в других местах, со всех языков. И мне не нравится в зависимости от Microsoft.VisualBasic.dll, когда я разрабатываю .NET. Я всегда предпочитаю System. *.
И тогда это всегда отчасти ограничено. Я вижу, что разработчики VB работают со своим приложением, когда они не могут найти что-то в пространстве имен My, потому что они не могут себе представить, что вы можете использовать что-то в пространстве имен System. Это, конечно, не проблема самого пространства имен.
Love the My! Все, что помогает мне быстрее выполнять работу и предоставляет код для решений, которые мне не нужно писать, тем лучше!
Я не пользуюсь им.
Я рассматриваю возможность создания рамки для VB.NET и использование пространства имен My, чтобы подключить ее к VB, кажется разумной идеей. Это?
Если это подходит, обязательно используйте его. Поскольку вы не предлагали никакой дополнительной информации о своей структуре, сказать сложно. Я бы не поставил вещи общего назначения в пространство имен My (например, My.Computer), потому что на самом деле нет никакого преимущества для его размещения. Тем не менее, помощники, ориентированные на приложения, хорошо вписываются.
Я использовал My в моих проектах VB.NET, и я не чувствую себя виноватым в этом. Я в первую очередь парень из C#, но пока я не перешел на C#, мы были магазином VB. На мой взгляд, пространство имен My - это хороший кусок синтаксического сахара. Так же, как я не смущен, чтобы использовать оператора Cace coalesce и другого сахара, я тоже не смущен, чтобы использовать сахар VB. (В какой-то мере я не буду использовать классические функции VB, которые все еще предоставляет .NET.)
Вставить ник в это пространство имен. Это пространство имен Microsoft, и так же, как вы ничего не ставите в Системе или Microsoft, не ставьте ничего под My. Это вызовет путаницу позже - если не для вас, то для других, которые поддерживают ваш код. Создайте собственное пространство имен для собственного кода.
Я часто использую My.Settings и My.Computer во время программирования на VB.NET. Мне особенно нравится My.Settings как альтернатива использованию ConfigurationManager.AppSettings, когда это уместно.
Я согласен с Джоном Руди в использовании My. Это синтаксический сахар, который делает жизнь более читаемой.
Вы также можете использовать его с C#, хотя не многие разработчики C#, похоже, его используют. – 2008-10-12 12:50:55
вот ссылка для заинтересованных: http://msdn.microsoft.com/en-us/library/ms173136.aspx – 2008-10-12 12:53:45