Недостатки конструкции C # (.NET) [закрыто]

Каковы самые большие недостатки дизайна в C # или .NET Framework в целом?

Пример: не существует строкового типа, не допускающего значения NULL, и вам нужно проверить DBNull при выборке значений из IDataReader.

Я категорически согласен с этим сообщением (для тех, кто жалуется на отсутствие ToString, есть атрибут отладчика, обеспечивающий настраиваемый формат для вашего класса).

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

1. ссылочные типы, не допускающие значения NULL, как дополнение к типам значений, допускающим значение NULL,
2. разрешить переопределение пустого конструктора структуры,
3. разрешить ограничениям универсального типа указывать запечатанные классы,
4. Я согласен с другим автором, который запрашивал произвольные подписи конструктора при использовании в качестве ограничений, т.е. гдеT : new(string) или гдеT : new(string, int)
5. Я также согласен с другим постером об исправлении событий, как для пустых списков событий, так и для параллельных настроек (хотя последнее сложно),
6. операторы должны быть определены как методы расширения, а не как статические методы класса (или, по крайней мере, не как статические методы),
7. разрешить статические свойства и методы для интерфейсов (в Java это есть, а в C # нет),
8. разрешить инициализацию событий в инициализаторах объектов (в настоящее время разрешены только поля и свойства),
9. почему синтаксис «инициализатор объекта» можно использовать только при создании объекта? Почему бы не сделать его доступным в любое время, т.е.var e = new Foo(); e { Bar = baz };
10. исправить квадратичное перечислимое поведение ,
11. все коллекции должны иметь неизменяемые моментальные снимки для итерации (т.е. изменение коллекции не должно приводить к недействительности итератора),
12. кортежи легко добавлять, но эффективный замкнутый алгебраический тип, например "Either<T> " - нет, поэтому мне бы хотелось каким-нибудь способом объявить закрытый алгебраический тип и обеспечить для него исчерпывающее сопоставление с образцом (в основном первоклассная поддержка шаблона посетителя, но намного эффективнее); так что просто возьмите перечисления, расширьте их исчерпывающей поддержкой сопоставления с образцом и не допускайте недопустимых случаев,
13. Мне бы очень хотелось поддержки сопоставления с образцом в целом, но, по крайней мере, для тестирования типов объектов; Мне также нравится синтаксис переключателя, предложенный в другом посте здесь,
14. Я согласен с другим сообщением о том, что System.IOклассы вроде бы Streamплохо спроектированы; любой интерфейс, требующий некоторых реализаций, NotSupportedExceptionявляется плохим дизайном,
15. IListдолжно быть намного проще, чем есть; фактически, это может быть верно для многих конкретных интерфейсов коллекций, например ICollection,
16. слишком много методов генерируют исключения, например, IDictionary,
17. Я бы предпочел более качественную форму проверенных исключений, чем та, которая доступна в Java (см. Исследование систем типов и эффектов, чтобы узнать, как это можно сделать),
18. исправить различные раздражающие угловые случаи в разрешении перегрузки универсального метода; например, попробуйте предоставить два перегруженных метода расширения, один из которых работает со ссылочными типами, а другой - с типами структуры, допускающими значение NULL, и посмотрите, как это нравится вашему выводу типа,
19. предоставить способ безопасного отражения имен полей и членов для интерфейсов, например INotifyPropertyChanged, которые принимают имя поля в виде строки; вы можете сделать это, используя метод расширения, который принимает лямбду с a MemberExpression, т.е. () => Foo, но это не очень эффективно,
    • Обновление: в C # 6.0 добавлен nameof()оператор для имен с одним членом, но он не работает в универсальных шаблонах ( nameof(T) == "T"вместо фактического имени аргумента типа: вам все равно нужно это сделать typeof(T).Name)) - и при этом он не позволяет вам получить строку «путь» , например, nameof(this.ComplexProperty.Value) == "Value"ограничение его возможных приложений.
20. разрешить операторы в интерфейсах и реализовать все основные числовые типы IArithmetic ; также возможны другие полезные общие интерфейсы оператора,
21. усложнить изменение полей / свойств объекта или, по крайней мере, разрешить аннотирование неизменяемых полей и заставить средство проверки типов применять его (просто относитесь к нему как к свойству только для получения данных, это несложно!); на самом деле объединять поля и свойства более разумным способом, поскольку нет смысла иметь и то, и другое; Автоматические свойства C # 3.0 - первый шаг в этом направлении, но они недостаточны,
    • Обновление: хотя в C # было readonlyключевое слово, а в C # 6.0 добавлены автоматические свойства только для чтения, хотя это не так строго, как настоящая языковая поддержка неизменяемых типов и значений.
22. упростить объявление конструкторов; Мне нравится подход F #, но другой пост здесь, который требует просто "новый" вместо имени класса, по крайней мере, лучше,

Полагаю, пока этого достаточно. Это все раздражения, с которыми я столкнулся на прошлой неделе. Я, вероятно, мог бы продолжать в течение нескольких часов, если бы действительно сосредоточился на этом. C # 4.0 уже добавляет именованные, необязательные аргументы и аргументы по умолчанию, что я категорически одобряю.

Теперь по одной необоснованной просьбе:

1. было бы очень-очень хорошо, если бы C # / CLR мог поддерживать полиморфизм конструкторов типов, т.е. дженерики над дженериками,

Довольно, пожалуйста? :-)

• Reset()метод на IEnumerator<T>была ошибка (для блоков итераторов, язык SPEC даже требования , что это бросает исключение)
• методы отражения, возвращающие массивы, по мнению Эрика, ошибкой
• ковариация массивов была и остается диковинкой
  • Обновление: В C # 4.0 с .NET 4.0 добавлена ​​поддержка ковариантности / контравариантности для общих интерфейсов (например, IEnumerable<out T>и Func<in T, out TResult>, но не конкретных типов (например List<T>).
• ApplicationException скорее впал в немилость - это было ошибкой?
• синхронизированные коллекции - хорошая идея, но не обязательно полезная в реальности: обычно вам нужно синхронизировать несколько операций ( Contains, тогдаAdd ), поэтому коллекция, которая синхронизирует отдельные операции, не так уж и полезна
  • Обновление: В System.Collections.Concurrentтипы , с TryAdd, GetOrAdd, TryRemoveи т.д. были добавлены в .NET Framework 4.0 - хотя методы , которые принимают заводскую делегат не гарантируют завод будет запущен только один раз за ключ.
• можно было бы больше использовать шаблон using/ lock- возможно, позволяя им совместно использовать повторно используемый (расширяемый?) синтаксис; вы можете смоделировать это, вернувшись IDisposableи используя using, но это могло быть более понятным
• блоки итераторов: нет простого способа проверки аргументов заблаговременно (а не лениво). Конечно, вы можете написать два связанных метода, но это некрасиво
• было бы неплохо более простая неизменяемость; C # 4.0 немного помогает , но недостаточно
• нет поддержки "этот параметр типа ссылки не может быть нулевым" - хотя контракты (в 4.0) в некоторой степени помогают в этом. Но синтаксис вроде Foo(SqlConnection! connection)(который вводит нулевую проверку / throw) был бы хорош (в отличие отint? т. Д.)
  • Обновление: это исправлено в C # 8.0 .
• отсутствие поддержки операторов и нестандартных конструкторов с дженериками; С # 4.0 немного решает эту проблему с помощью dynamic, или вы можете включить его так
• переменная итератора объявляется за пределами while вforeach расширении, что означает, что анон-методы / лямбда-выражения захватывают единственную переменную, а не одну на итерацию (болезненно с потоковой / асинхронной / и т. д.)
  • Обновление: это было исправлено в C # 5.0 .

TextWriter - это базовый класс StreamWriter. что за?

Это всегда меня до крайности смущает.

Маленький любимец C # - конструкторы используют синтаксис C ++ / Java, в котором имя конструктора совпадает с именем класса.

New() или же ctor() было бы намного лучше.

И конечно, такие инструменты, как coderush, делают эту проблему менее сложной для переименования классов, но с точки зрения удобочитаемости New () обеспечивает большую ясность.

Я не понимаю, что ты не можешь

где T: new (U)

Таким образом, вы объявляете, что универсальный тип T имеет конструктор, отличный от конструктора по умолчанию.

редактировать:

Я хочу сделать это:

public class A 
{
    public A(string text) 
    {

    }
}


public class Gen<T> where T : new(string text) 
{

}

Я очень удивлен, что первым упомянул об этом:

Типизированные наборы данных ADO.NET не раскрывают столбцы, допускающие значение NULL, как свойства типов, допускающих значение NULL. Вы должны уметь написать это:

int? i = myRec.Field;
myRec.Field = null;

Вместо этого вы должны написать это, что просто глупо:

int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();

Это раздражало в .NET 2.0, и еще больше раздражает то, что вам приходится использовать jiggery-pokery, как указано выше, в ваших красивых аккуратных запросах LINQ.

Также раздражает то, что сгенерированный Add<TableName>Rowметод также нечувствителен к понятию обнуляемых типов. Тем более что сгенерированныеTableAdapter методов нет.

В .NET не так много всего, что заставляет меня чувствовать, что команда разработчиков сказала: «Хорошо, ребята, мы достаточно близки - отправьте его!» Но это точно так.

1. Я не большой поклонник классов Stream, StringWriter, StringReader, TextReader, TextWriter ... просто не понятно, что к чему.
2. IEnumerable.Reset генерирует исключение для итераторов. У меня есть некоторые сторонние компоненты, которые всегда вызывают сброс при связывании данных, и для их использования требуется сначала привести к списку.
3. Сериализатор Xml должен иметь сериализованные элементы IDictionary
4. Я совершенно забыл о HttpWebRequest и FTP API, какая боль у меня .... (спасибо за комментарий Николас, чтобы напомнить мне об этом :-)

редактировать
5. Еще одно мое раздражение - это то, что System.Reflection.BindingFlags может использоваться по-разному в зависимости от используемого вами метода. Например, в FindFields что означает CreateInstance или SetField? Это тот случай, когда они перегрузили смысл этого перечисления, что сбивает с толку.

Я не знаю, могу ли я сказать, что это недостаток дизайна, но было бы очень хорошо, если бы вы могли вывести лямбда-выражение так же, как в VB:

VB:

Dim a = Function(x) x * (x - 1)

C #

Было бы неплохо, если бы можно было сделать так:

var a = x => x * (x - 1);

Вместо того, чтобы делать это:

Func<int, int> a = x => x * (x - 1);

Я понимаю, что это не намного дольше, но в Code Golf каждый персонаж чертовски важен! Разве они не принимают это во внимание при разработке этих языков программирования? :)

1. Класс System.Object :

   • Equals и GetHashCode - не все классы сопоставимы или хешируемы, следует перенести в интерфейс. На ум приходит IEquatable или IComparable (или аналогичный).

   • ToString - не все классы можно преобразовать в строку, их следует переместить в интерфейс. На ум приходит IFormattable (или аналогичный).

2. Свойство ICollection.SyncRoot :

   • Способствует плохому дизайну, внешний замок почти всегда полезнее.

3. Дженерики должны были быть там с самого начала:

   • Пространство имен System.Collections содержит множество более или менее устаревших классов и интерфейсов.

Одна из вещей, которая меня раздражает, - это Predicate<T> != Func<T, bool>парадокс. Они оба являются делегатами типа, T -> boolно не совместимы по присваиванию.

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

Мы так много знаем о праве методах объектно-ориентированного программирования. Разделение, программирование по контракту, избежание неправильного наследования, правильное использование исключений, открытый / закрытый принципал, заменяемость Лискова и т. Д. Как бы то ни было, в .Net-фреймворках не используются лучшие практики.

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

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

Мне не нравится оператор switch в C #.

Я бы хотел что-то подобное

switch (a) {
  1    : do_something;
  2    : do_something_else;
  3,4  : do_something_different;
  else : do_something_weird; 
}

Так что больше никаких разрывов (легко забыть) и возможности разделять запятыми разные значения.

События в C #, где вы должны явно проверять слушателей. Разве не в этом был смысл событий транслировать для всех, кто там окажется? Даже если их нет?

Ужасное (и совершенно незаметное для большинства) поведение вложенных / рекурсивных итераторов O (N ^ 2) .

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

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

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

Некоторые классы реализуют интерфейсы, но они не реализуют многие методы этого интерфейса, например, Array реализует IList, но 4 из 9 методов выдают NotSupportedException http://msdn.microsoft.com/en-us/library/system.array_members .aspx

Статические члены и вложенные типы в интерфейсах.

Это особенно полезно, когда член интерфейса имеет параметр типа, специфичного для интерфейса ( например , enum). Было бы неплохо вложить тип enum в тип интерфейса.

Ужасно опасный дефолтный характер событий. Тот факт, что вы можете вызвать событие и оказаться в несогласованном состоянии из-за удаления подписчиков, просто ужасен. См. Отличные статьи Джона Скита и Эрика Липперта для получения дополнительной информации по этой теме.

• null везде.

• const нигде.

• API несовместимы, например, изменение массива возвращает void но добавление к нему StringBufferвозвращает тот же изменяемый StringBuffer.

• Интерфейсы коллекций несовместимы с неизменяемыми структурами данных, например Add , в System.Collections.Generic.IList<_>не может возвращать результат.

• Нет структурной типизации, поэтому вы пишете System.Windows.Media.Effects.SamplingMode.Bilinear вместо просто Bilinear.

• Мутабельный IEnumerator интерфейс, реализуемый классами, когда он должен быть неизменяемым struct.

• Равенство и сравнение беспорядок: у вас есть , System.IComparableи Equalsно тогда вы также получили System.IComparable<_>, System.IEquatable,System.Collections.IComparer , System.Collections.IStructuralComparable, System.Collections.IStructuralEquatable, System.Collections.Generic.IComparerи System.Collections.Generic.IEqualityComparer.

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

0 подрабатывает enum

особенности enum: http://blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

как показано на этом хорошем примере: http://plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

мое предложение, используйте знак «@» с пользой:

вместо:

если ((myVar & MyEnumName.ColorRed)! = 0)

использовать этот:

если ((myVar & MyEnumName.ColorRed)! = @ 0)

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

• DateTime.Now == DateTime.Now в большинстве, но не во всех случаях.

• Stringкоторый является неизменным, имеет множество опций для построения и манипуляции, но StringBuilder(который является изменяемым) - нет.

• Monitor.Enterи Monitor.Exitдолжны были быть методами экземпляра, поэтому вместо создания определенного объекта для блокировки вы можете создать новый a Monitorи заблокировать его.

• Деструкторы никогда не должны были называться деструкторами. Спецификация ECMA называет их финализаторами, что гораздо меньше сбивает с толку C ++, но спецификация языка по-прежнему называет их деструкторами.

Иногда меня раздражает то, как мы используем свойства. Мне нравится думать о них как о эквиваленте методов Java getFoo () и setFoo (). Но это не так.

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

С этой целью мне всегда хотелось (здесь я в основном размышляю вслух, я просто хотел бы сделать что-то подобное), чтобы я мог как-то расширить синтаксис свойств. Представьте себе что-то вроде этого:

private string password;

public string Password
{
    // Called when being set by a deserializer or a persistence
    // framework
    deserialize
    {
       // I could put some backward-compat hacks in here. Like
       // weak passwords are grandfathered in without blowing up
       this.password = value;
    }
    get
    {
       if (Thread.CurrentPrincipal.IsInRole("Administrator"))
       {
           return this.password;
       }
       else
       {
           throw new PermissionException();
       }
    }
    set
    {
       if (MeetsPasswordRequirements(value))
       {
           throw new BlahException();
       }
       this.password = value;
    }
    serialize
    {
        return this.password;
    }
}

Я не уверен, полезно ли это или как будет выглядеть доступ к ним. Но я просто хочу, чтобы я мог делать больше со свойствами и действительно относился к ним как к методам get и set.

Методы расширения хороши, но это уродливый способ решить проблемы, которые можно было бы решить более чисто с помощью настоящих миксинов (посмотрите на Ruby, чтобы понять, о чем я говорю) в отношении миксинов. Действительно хороший способ добавить их в язык - разрешить использование дженериков для наследования. Это позволяет вам расширять существующие классы приятным объектно-ориентированным способом:

public class MyMixin<T> : T
{
    // etc...
}

это можно использовать, например, для расширения строки:

var newMixin = new MyMixin<string>();

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

Извините за тираду :-)

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

Кроме того, нет способа двоичного исправления исполняемых файлов .NET во время выполнения и нет способа указать частные версии библиотек .NET framework без двоичного исправления собственных библиотек (для перехвата вызова загрузки), а ILDASM не распространяется, поэтому я не могу автоматизировать в любом случае патч.

• Возможность вызвать метод расширения для нулевой переменной спорна, например

  объект a = null; a.MyExtMethod (); // это вызывается, предположим, что где-то он определил MyExtMethod

  Это может быть удобно, но это неоднозначно по темам исключений с нулевой ссылкой.

• Один недостаток в названии. Буква «C» в слове «конфигурация» в System.configuration.dll должна начинаться с заглавной буквы.

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

Метод .Parameters.Add () в SqlCommand в V1 фреймворка был ужасно спроектирован - одна из перегрузок в основном не работала бы, если бы вы передали параметр со значением (int) 0 - это привело к их созданию метод .Parameters.AddWithValue () в классе SqlCommand.

1. Нет подмножеств ICollection<T>и IList<T>; как минимум, ковариантный интерфейс коллекции только для чтенияIListSource<out T> (с перечислителем, индексатором и счетчиком) был бы чрезвычайно полезен.
2. .NET не поддерживает слабые делегаты . Обходные пути в лучшем случае неуклюжие, а обходные пути на стороне слушателя невозможны при частичном доверии (требуется ReflectionPermission).
3. Универсальная унификация интерфейса запрещена, даже если она имеет смысл и не вызывает проблем.
4. В отличие от C ++, ковариантные возвращаемые типы в .NET не допускаются.
5. Побитовое сравнение двух типов значений на равенство невозможно. В функциональной « постоянной » структуре данных я писалTransform(Sequence<T>, Func<T,T>) функцию, которая должна была быстро определить, возвращает ли функция то же значение или другое значение. Если функция не изменяет большую часть / все свои аргументы, то выходная последовательность может совместно использовать часть / всю память из входной последовательности. Без возможности побитового сравнения любого типа значения T необходимо использовать гораздо более медленное сравнение, что сильно снижает производительность.
6. .NET, похоже, не в состоянии поддерживать специальные интерфейсы (вроде тех, что предлагаются в Go или Rust) с высокой производительностью. Такие интерфейсы позволили бы вам выполнить приведение List<T>к гипотетическому IListSource<U>(где T: U), даже если класс явно не реализует этот интерфейс. Есть как минимум три разные библиотеки (написанные независимо) для обеспечения этой функциональности (конечно, с недостатками производительности - если бы идеальный обходной путь был возможен, было бы несправедливо называть это недостатком в .NET).
7. Другие проблемы с производительностью: IEnumerator требует двух вызовов интерфейса на итерацию. Простые указатели на методы (открытые делегаты размера IntPtr) или делегаты с типом значений (IntPtr * 2) невозможны. Массивы фиксированного размера (произвольного типа T) не могут быть встроены в классы. Нет WeakReference<T>(вы можете легко написать свой собственный, но он будет использовать внутренние преобразования).
8. Тот факт, что идентичные типы делегатов считаются несовместимыми (без неявного преобразования), в некоторых случаях меня раздражал (например, Predicate<T>vs Func<T,bool>). Мне часто хотелось бы иметь структурную типизацию для интерфейсов и делегатов, чтобы добиться более слабой связи между компонентами, потому что в .NET недостаточно, чтобы классы в независимых библиотеках DLL реализовали один и тот же интерфейс - они также должны иметь общую ссылку на третью DLL, определяющая интерфейс.
9. DBNull.Valueсуществует, хотя nullи одинаково хорошо служил бы той же цели.
10. В C # нет оператора ?? =; ты должен написать variable = variable ?? value. Действительно, в C # есть несколько мест, в которых без нужды отсутствует симметрия. Например, вы можете писать if (x) y(); else z();(без фигурных скобок), но не можете писать try y(); finally z();.
11. При создании потока невозможно заставить дочерний поток наследовать локальные значения потока от родительского потока. BCL не только не поддерживает это, но вы не можете реализовать это самостоятельно, если не создадите все потоки вручную; даже если бы произошло событие создания потока, .NET не может сказать вам «родителей» или «потомков» данного потока.
12. Тот факт, что для разных типов данных существуют два разных атрибута длины, «Длина» и «Счетчик», является незначительной неприятностью.
13. Я мог бы бесконечно говорить о плохом дизайне WPF ... и WCF (хотя и весьма полезный для некоторых сценариев) также полон бородавок. В целом, раздутость, неинтуитивность и ограниченная документация многих новых подбиблиотек BCL заставляют меня неохотно их использовать. Многие из новых вещей могли бы быть намного проще, меньше, проще в использовании и понимании, более слабо связаны, лучше документированы, применимы к большему количеству вариантов использования, быстрее и / или более строго типизированы.
14. Меня часто укусила ненужная связь между геттерами и сеттерами свойств: в производном классе или производном интерфейсе вы не можете просто добавить сеттер, когда базовый класс или базовый интерфейс имеет только геттер; если вы переопределите геттер, вам не разрешено определять сеттер; и вы не можете определить сеттер как виртуальный, а получатель как не виртуальный.

Одна вещь , которая галочкой меня в 1.x было при использовании System.Xml.XmlValidatingReader, то ValidationEventHandler«s ValidationEventArgsне выставляет Базового XmlSchemaException(помечено внутренний) , который имеет всю полезную информацию , как linenumberи position. Вместо этого вы должны проанализировать это из свойства строки сообщения или использовать отражение, чтобы раскопать его. Не очень хорошо, если вы хотите вернуть конечному пользователю более исправленную ошибку.

Не нравится, что вы не можете использовать значения одного перечисления в другом перечислении, например:

    enum Colors { white, blue, green, red, black, yellow }

    enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow } 

Неявно типизированные переменные были реализованы плохо IMO. Я знаю, что вам действительно следует использовать их только при работе с выражениями Linq, но раздражает, что вы не можете объявить их вне локальной области.

Из MSDN:

• var может использоваться только тогда, когда локальная переменная объявлена ​​и инициализирована в том же операторе; переменная не может быть инициализирована значением NULL, группой методов или анонимной функцией.
• var нельзя использовать в полях в области класса.
• Переменные, объявленные с помощью var, нельзя использовать в выражении инициализации. Другими словами, это выражение допустимо: int i = (i = 20); но это выражение вызывает ошибку времени компиляции: var i = (i = 20);
• Несколько неявно типизированных переменных не могут быть инициализированы в одном операторе.
• Если тип с именем var находится в области видимости, то ключевое слово var будет преобразовано в это имя типа и не будет рассматриваться как часть объявления неявно типизированной локальной переменной.

Я считаю, что это плохая реализация, потому что они называют это var, но это далеко не вариант. На самом деле это просто сокращенный синтаксис, позволяющий не вводить полное имя класса (кроме случаев, когда он используется с Linq)