1. C# / Говнокод #13421

    +128

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    public void BuildInsertClause(OleDbCommand cmd, ObjectState objState)
            {
                  StringBuilder builder = new StringBuilder();
                  ..........
                  cmd.CommandText = builder.ToString() + "(" + columns.ToString() + ") VALUES (" +
                  values.ToString() + ")";
            }

    http://solidcoding.blogspot.ru/2008/01/linq-to-excel-provider-25.html
    Еще много смешного, для затравки:

    object val = reader[col.GetSelectColumn()];
    if (val is DBNull)
    {
    val = null;
    }

    Запостил: neeedle, 15 Июля 2013

    Комментарии (17) RSS

    • Походу дела автор решил не заморачиваться с параметризованным SQL'ем.
      Вот ещё в догонку:
      http://msdn.microsoft.com/en-us/library/way3dy9w.aspx
      >Еще много смешного, для затравки:
      А какие ещё есть варианты?
      Ответить
      • Это не для sql-a, для эксельки.
        И смысл гк был в том, что совместно с плюсиками используется стрингбилдер, который как бы и есть альтернатива.
        >>А какие ещё есть варианты?

        object val = reader[col.GetSelectColumn()] as DBNull;
        Ответить
        • >что совместно с плюсиками используется стрингбилдер, который как бы и есть альтернатива.
          Небось, автор хотел типизировать.
          >object val = reader[col.GetSelectColumn()] as DBNull;
          Вариант. Только лучше так:
          String val=reader[col.GetSelectColumn()] as String;

          Иначе мы только DBNull/null получать будем.
          Ответить
          • Да, так лучше. Почему-то не подумал, что DBNull это практически тот же самый null.
            Ответить
    • Кто вообще в наше время использует голый SQL без ORM?
      Ответить
      • >>Кто вообще в наше время использует голый SQL без ORM?
        Оставшиеся вменяемыми люди.
        А вот клеить запросы - "я в пхпешники пойду там меня научат!"
        Ответить
      • Неправильно поставлен вопрос. Кто использует ORM, кроме заедушных анскиллябр, не осиливших оптимальное написание запросов?
        Ответить
        • > оптимальное написание запросов
          На си?
          Ответить
          • Почему бы и нет? Любая база данных — это массив, к которому можно написать оптимальный обход на Си.
            Ответить
      • Звучит так, словно ORM - панацея.
        Ответить
      • а что считать голым SQL?
        просто аффтар ниасилил параметризированные prepared statements и клеит запросы как заедушный пхпшник
        Ответить
      • Я использую ORM только в тех случаях, когда проект не особо сложный и без жестких манипуляций и оптимизации можно обойтись обычным ef.
        Но если вам нужно отчеты большие выводить, создавать временные таблицы и много чего другого, вам руки оторвут за использование ORM.
        Ответить
        • Можно с успехом совмещать ORM и нативный SQL
          Ответить
          • Тоже вариант, но чаще всего, если уж нужен sql, то быстрее и проще использовать только его.
            Ответить
          • Как вариант, можно годами упираться в ограничения ORM, долго допиливать и в итоге всё равно перейти на SQL.
            Ответить
      • Видимо, только очень недалёкие люди, чья приверженность производительности противоречит всепобеждающей идеологии ORM.
        Ответить
    • И такое бывало
      builder.Append(string.Format("{0}", "(" + a.ToString() + ")")
      Ответить

    Добавить комментарий