Хорошая практика для создания методов расширения, применимых к System.Object?

Нет, это не лучшая практика. Вы хотите применить методы расширения к самой низкой возможной точке. Я считаю, что есть время и место для (почти) всего, но методы расширения System.Object почти никогда не подойдут. Вы должны иметь возможность применять такие методы расширения намного дальше по стеку наследования. В противном случае это загромождает ваш intellisense и, вероятно, в конечном итоге будет неправильно использоваться / зависеть от других разработчиков.

Однако методы расширения для объектов данных для работы со значениями Null - это очень хорошее применение методов расширения. Подумайте о том, чтобы передать их вам OleDbDataReader. У меня есть общий метод расширения под названием ValueOrDefault that. . . ну я тебе просто покажу:

<Extension()> _
Public Function ValueOrDefault(Of T)(ByVal r As DataRow, ByVal fieldName As String) As T
    If r.IsNull(fieldName) Then
        If GetType(T) Is GetType(String) Then
            Return CType(CType("", Object), T)
        Else
            Return Nothing
        End If
    Else
        Return CType(r.Item(fieldName), T)
    End If
End Function

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

Помещение методов расширения в отдельное пространство имен лучше, чем ничего (это совершенно допустимое использование пространств имен; Linq использует это), но в этом нет необходимости. Чтобы применить эти методы к различным объектам базы данных, примените методы расширения к IDataRecord.

Отрывок из книги «Рекомендации по проектированию каркаса».

Избегайте определения методов расширения в System.Object, за исключением случаев крайней необходимости. При этом имейте в виду, что пользователи VB не смогут использовать определенные таким образом методы расширения и, как таковые, они не смогут воспользоваться преимуществами удобства использования / синтаксиса, которые приходят с методами расширения.

Это связано с тем, что в VB объявление переменной как объекта приводит к тому, что все вызовы методов для нее должны быть связаны с поздним связыванием, в то время как привязки к методам расширения определяются во время компиляции (ранняя привязка). Например:

public static class SomeExtensions{
     static void Foo(this object o){…} } … Object o = … o.Foo(); 

В этом примере вызов Foo в VB завершится ошибкой. Вместо этого синтаксис VB должен быть просто: SomeExtensions.Foo (o)
Обратите внимание, что рекомендации применяются к другим языкам, где присутствует такое же поведение привязки или где методы расширения не поддерживаются.

Не рекомендуется этого делать в Руководстве по разработке фреймворка. . Однако эти рекомендации предназначены специально для фреймворков, поэтому, если вы сочтете их очень полезными в своем (линейном) бизнес-приложении, сделайте это.

Но имейте в виду, что добавление этих методов расширения к объекту может загромождать IntelliSense и может сбить с толку других разработчиков. Возможно, они не ожидают увидеть эти методы. В этом случае просто используйте старомодные статические методы :-)

По этой причине я очень консервативен в использовании методов расширения. Но это не значит, что я не считаю их полезными. Конечно нет! Я даже написал библиотеку для проверки предварительных условий, в которой широко используются методы расширения. Я даже изначально определил методы расширения на System.Object, когда начал писать эта библиотека. Однако, поскольку это многоразовая библиотека, которую используют разработчики VB, я решил удалить эти методы расширения на System.Object.

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

Если вы объедините это с кодом, который следует принципу единой ответственности, вам нужно будет импортировать это пространство имен только в относительно небольшое количество классов.

При таких обстоятельствах такие методы расширения могут быть приемлемыми.

Возможно, подумайте о добавлении методов расширения в интерфейс IDataRecord? (который реализует ваш OleDbDataReader)

public static class DataRecordExtensions
{
    public static string GetStringSafely(this IDataRecord record, int index)
    {
        if (record.IsDBNull(index))
            return string.Empty;

         return record.GetString(index);            
    }

    public static Guid GetGuidSafely(this IDataRecord record, int index)
    {
        if (record.IsDBNull(index))
            return default(Guid);

        return record.GetGuid(index);
    }

    public static DateTime GetDateTimeSafely(this IDataRecord record, int index)
    {
        if (record.IsDBNull(index))
            return default(DateTime);

        return record.GetDateTime(index);
    }
}

Помимо уже упомянутых причин, следует иметь в виду, что методы расширения на System.Object не поддерживаются в VB (пока переменная статически типизирована как System.Object, а если переменная не набрана статически как Object, вам лучше расширить другую более конкретный тип).

Причина этого ограничения - обратная совместимость. См. этот вопрос для получения дополнительной информации.

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

public static T ChangeType<T>(this object obj) where T : new()
{
    try
    {
        Type type = typeof(T);
        return (T)Convert.ChangeType(obj, type);
    }
    catch
    {
        return new T();
    }
}

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

Работает вот так ...

int i = "32".ChangeType<int>();
bool success = "true".ChangeType<bool>();