2012-06-29 1 views
3

Я хотел знать, какие преимущества, если таковые имеются, вызвать любой из этих методов и почему?
Являются ли они функционально эквивалентными, или я должен всегда выбирать один за другим?Assembly.GetAssembly (type) vs type.Assembly

+0

Они по существу эквивалентны, но только разные исключения, если 'type' является' null'. ('ArgumentNullException' vs' NullPointerException') NPE обычно бесполезны и их всегда следует предотвращать с помощью нулевых проверок. Имея это бросить «ArgumentNullException», вы выглядите намного лучше. –

+0

Можно ли предположить, что, как отметил @JeffMercado, они по сути эквивалентны, и Microsoft просто хотела предоставить метод ('Assembly.GetType (type)') и свойство ('type.Assembly'). – SNH

ответ

2

AFAIK они функционально эквивалентны, однако Assembly.GetAssembly (тип) не доступен в ядро-CLR (Silverlight и т.п.)

Вы бы получить различные ошибки на основе того или не ваш Type является недействительным , Type.Assembly будет генерировать исключение NullReferenceException (естественно), тогда как Assembly.GetAssembly(Type) будет генерировать исключение ArgumentNullException. На основе вашего кода вы можете предпочесть тот или иной.

EDIT: Глядя на источник, для Assembly.GetAssembly:

public static Assembly GetAssembly(Type type) 
{ 
    if (type == null) 
     throw new ArgumentNullException("type"); 
    Contract.EndContractBlock(); 

    Module m = type.Module; 
    if (m == null) 
     return null; 
    else 
     return m.Assembly; 
} 

В то время как System.Type.Assembly:

public abstract Assembly Assembly { 
    get; 
} 

Если я правильно помню, System.Type для типов во время выполнения их собственные подклассы (или что-то так что) Поэтому я думаю, что каждый может быть переопределен и просто возвращает ссылку на сборку. Помимо этого, я не думаю, что есть какая-то существенная разница для вас, чтобы беспокоиться о том, что ваш код за пределами нулевой обработки зависит от вас. (Или, если вы работаете в Core-CLR, в этом случае вы не имеете Assembly.GetAssembly в любом случае, так что вы сусла использовать Type.Assembly)

0

От the documentation for Type.Assembly

Если текущий объект Type представляет построенный общий тип, это свойство возвращает сборку, которая содержит определение типа .

Например, предположим, что вы создаете сборку с именем MyGenerics.dll, который содержит обобщенный тип определения MyGenericStack<T>. При создании экземпляра MyGenericStack<int> в другого узла, свойство Ассамблеи для конструируемого типа возвращает объект Assembly, представляющий MyGenerics.dll

Из документации для Assembly.GetAssembly:

Для того, чтобы позвонить этот метод должен иметь объект Type, что означает , что сборка, в которой определяется класс, уже должна быть загружена .

+0

Звучит совершенно одинаково для меня. Как вы могли бы называть 'myType.Assembly', если у вас нет загруженного объекта типа? –

+0

Да, я не знаю, почему они делают большую сделку из общего случая для типа.Assembly', но они, похоже, считают, что это важно. –

+0

Я читал, что как 'MyGenericStack ' может быть технически не существовать в 'MyGenerics.dll' и, таким образом, быть создан в другом месте кода, чтобы поддерживать здравомыслие программиста, контрольные точки типа в сборке' MyGenericStack '. Стоит упомянуть, я полагаю, чтобы избежать двусмысленности. –

 Смежные вопросы

  • Нет связанных вопросов^_^