С# namespace alias - какой смысл?

Ответ 1

Это псевдоним типа, а не псевдоним пространства имен; полезно устранить неоднозначность - например, против:

using WinformTimer = System.Windows.Forms.Timer;
using ThreadingTimer = System.Threading.Timer;

(ps: спасибо за выбор Timer; -p)

В противном случае, если вы используете как System.Windows.Forms.Timer, так и System.Timers.Timer в том же файле, вам нужно будет указывать полные имена (поскольку Timer может ввести в заблуждение).

Он также играет роль с алиасами extern для использования типов с тем же самым полным именем типа из разных сборок - редко, но полезно для поддержки.

На самом деле, я вижу другое использование: когда вы хотите быстрый доступ к типу, но не хотите использовать регулярный using, потому что вы не можете импортировать некоторые конфликтующие методы расширения... немного запутанные, но... вот пример...

namespace RealCode {
    //using Foo; // can't use this - it breaks DoSomething
    using Handy = Foo.Handy;
    using Bar;
    static class Program {
        static void Main() {
            Handy h = new Handy(); // prove available
            string test = "abc";            
            test.DoSomething(); // prove available
        }
    }
}
namespace Foo {
    static class TypeOne {
        public static void DoSomething(this string value) { }
    }
    class Handy {}
}
namespace Bar {
    static class TypeTwo {
        public static void DoSomething(this string value) { }
    }
}

Ответ 2

Я использую его, когда у меня есть несколько пространств имен с конфликтующими подпространствами имен и/или именами объектов, вы могли бы просто сделать что-то вроде [в качестве примера]:

using src = Namespace1.Subspace.DataAccessObjects;
using dst = Namespace2.Subspace.DataAccessObjects;

...

src.DataObject source = new src.DataObject();
dst.DataObject destination = new dst.DataObject();

Что в противном случае нужно было бы написать:

Namespace1.Subspace.DataAccessObjects.DataObject source = 
  new Namespace1.Subspace.DataAccessObjects.DataObject();

Namespace2.Subspace.DataAccessObjects.DataObject dstination = 
  new Namespace2.Subspace.DataAccessObjects.DataObject();

Это экономит массу ввода и может использоваться для упрощения чтения кода.

Ответ 3

В дополнение к указанным примерам, псевдонимы типов (а не псевдонимы пространства имен) могут быть полезны при многократном обращении к родовым типам:

Dictionary<string, SomeClassWithALongName> foo = new Dictionary<string, SomeClassWithALongName>();

private void DoStuff(Dictionary<string, SomeClassWithALongName> dict) {}

Versus:

using FooDict = Dictionary<string, SomeClassWithALongName>;

FooDict foo = new FooDict();

private void DoStuff(FooDict dict) {}

Ответ 4

Краткость.

Есть дополнительные преимущества для обеспечения ясности между пространствами имен, которые разделяют имена типов, но по сути это просто сахар.

Ответ 5

Я всегда использую его в таких ситуациях

using Utility = MyBaseNamespace.MySubNamsepace.Utility;

где Utility в противном случае имел бы другой контекст (например, MyBaseNamespace.MySubNamespace.MySubSubNamespace.Utility), но я ожидаю/предпочитаю Utility всегда указывать на один конкретный класс.

Ответ 6

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

namespace Something.From.SomeCompanyA {
    public class Foo {
        /* ... */
    }
}

namespace CompanyB.Makes.ThisOne {
    public class Foo {
        /* ... */
    }
}

Вы можете использовать псевдонимы, чтобы сделать компилятор счастливым и сделать вещи более понятными для вас и других в вашей команде:

using CompanyA = Something.From.CompanyA;
using CompanyB = CompanyB.Makes.ThisOne;

/* ... */

CompanyA.Foo f = new CompanyA.Foo();
CompanyB.Foo x = new CompanyB.Foo();

Ответ 7

Мы определили псевдонимы пространства имен для всех наших пространств имен. Это позволяет легко увидеть, откуда приходит класс, например:

using System.Web.WebControls;
// lots of other using statements

// contains the domain model for project X
using dom = Company.ProjectX.DomainModel; 
// contains common web functionality
using web = Company.Web;
// etc.

и

// User from the domain model
dom.User user = new dom.User(); 
// Data transfer object
dto.User user = new dto.User(); 
// a global helper class
utl.SomeHelper.StaticMethod(); 
// a hyperlink with custom functionality
// (as opposed to System.Web.Controls.HyperLink)
web.HyperLink link = new web.HyperLink(); 

Мы определили некоторые рекомендации о том, как псевдонимы должны быть названы, и каждый использует их.

Ответ 8

В одном случае это очень удобно при кодировании в Visual Studio.

Случай использования. Скажем, я должен использовать только несколько классов, например. SqlConnection из пространства имен System.Data. В обычном режиме я импортирую пространство имен System.Data.SqlClient в верхней части файла *.cs, как показано ниже:

using System.Data;

Теперь посмотри на мой intellisense. Он сильно размножается со множеством классов на выбор, набирая редактор кода. Я не собираюсь использовать целую кучу классов вообще:

Поэтому я предпочел бы использовать псевдоним в верхней части моего *.cs файла и получить четкое представление intellisense:

using SqlDataCon = System.Data.SqlClient.SqlConnection

Теперь взгляните на мой взгляд на intellisense. Он сверхчистый и суперчистый.

Ответ 9

Я считаю, что псевдонимы очень полезны при модульном тестировании. Когда вы пишете модульные тесты, общепринятой практикой является объявление объекта для тестирования как

MyClass myClassUT;

является myClassUT субъектом U nder T est. Но что, если вы хотите написать модульные тесты для статического класса со статическими методами? Затем вы можете создать псевдоним, подобный этому:

using MyStaticClassUT = Namespace.MyStaticClass;

Затем вы можете написать свои модульные тесты следующим образом:

public void Test()
{
    var actual = MyStaticClassUT.Method();
    var expected = ...
}

и вы никогда не теряете зрение, что испытуемый находится.

Ответ 10

Одна из причин, по которой я знаю; Он позволяет использовать более короткие имена, если вы столкнулись с именами из импортированных пространств имен. Пример:

Если вы объявили using System.Windows.Forms; и using System.Windows.Input; в том же файле при доступе к ModifierKeys, вы можете обнаружить, что имя ModifierKeys находится в пространствах имен System.Windows.Forms.Control и System.Windows.Input. Итак, объявив using Input = System.Windows.Input;, вы можете получить System.Windows.Input.ModifierKeys через Input.ModifierKeys.

Я не байт С#, но пространство имен псевдонимов кажется мне "лучшей практикой". Таким образом, вы знаете, что получаете, и все еще не нужно вводить слишком много.