c# - 在 ORM 中使用字符串格式的 sql 是一个好习惯吗

Question

我在 ORM (Bltoolkit) 中使用字符串格式的 sql。我不喜欢在没有必要的情况下使用 Linq，因为

• 使用 Linq 很难构建复杂的查询。没有足够的资源来使用 Linq 构建复杂的查询。
• 通过将字符串 sql 与 ORM 结合使用，您仍在改进 SQL 查询的实践。否则你的查询就会中断(我想 Linq 不会改进你的 sql 查询)。
• 您仍然可以使用绑定(bind)参数来保护您的查询免遭 SQL 注入(inject)。

你的想法是什么？这是一个好的做法吗？

在没有 Linq 的情况下使用 ORM(对于我的情况，BlToolkit)的示例如下:

        var db = new Veritabani("HstConn");

        try
        {
            var sorgu = @"select t.tcno ""KullaniciAdi"", t.ad ""Ad"", t.soyad ""Soyad"", t.kurum_kodu ""KurumKodu"", 
                                 t.ilkodu ""IlKodu"", t.kurum_turu ""KurumTuru"", t.e_posta ""Eposta"", t.dogrulama_kodu ""DogrulamaKodu""
                            from saglikcalisanlari t
                           where tcno = :kullaniciAdi
                             and sifre = :sifre";

            return db.SetCommand(sorgu,
                                 db.Parameter(":kullaniciAdi", kullaniciAdi.Trim()),
                                 db.Parameter(":sifre", sifre.Trim().Md5Hash())).ExecuteObject<SaglikCalisani>();
        }
        catch (Exception exc)
        {
            throw new Exception("Veritabanı Hatası: " + exc.Message);
        }
        finally
        {
            db.Close();
            db.Dispose();
        }

Answer 1

这始终是主观的并且依赖于上下文。也许真正的问题是“你真的会针对不同的数据库吗”。如果答案是“否”，那么固定 SQL 很可能就可以了。如果您需要针对多个不同的后端，那么像 HQL 或 ESQL 这样的抽象可能更合适 - 这与 LINQ 不同，但仍然独立于平台......左右。

在很多情况下，您需要手动调整 SQL，因为坦率地说，在复杂的情况下，开发人员的性能将在十分之九的情况下胜过生成器(LINQ 等)(根据欧盟部门的一项研究)发明了统计)。

只要正确参数化，SQL 本身就可以在这些场景中。

stackoverflow.com广泛使用手写 TSQL，因为:

• 我们没有计划更改后端，如果我们这样做:查询只是冰山一角
• 我们真的非常关心性能:
  • 解析表达式树 (LINQ) 或 DSL (HSQL/ESQL) 来生成 TSQL 需要时间
  • 我们希望 TSQL 能够精心编写并进行定制测试
  • 我们确实在我们使用的工具中发现了测量到的性能问题，即使使用预编译的 LINQ 查询也是如此
• 我们编写了自己的工具(“dapper”)来删除我们绝对需要的所有功能 - 使其简单地查询输入，对象输出
• 以及我们自己的工具(“迷你分析器”)来实时监控网站的性能