既然我们拥有Micro ORM，内联SQL是否仍被列为不良做法？

这是一个开放式的问题，但我想提出一些意见，因为我成长于一个以内联SQL脚本为标准的世界，然后我们都非常了解基于SQL注入的问题以及sql当时多么脆弱在各处进行字符串操作。

然后是ORM的曙光，您在其中向ORM解释查询并让它生成自己的SQL，在很多情况下，这种查询不是最佳方法，但又安全又容易。有关ORM或数据库抽象层的另一个好处是，SQL是在考虑数据库引擎的情况下生成的，因此我可以将Hibernate / Nhibernate与MSSQL，MYSQL一起使用，而我的代码从未更改，它只是一个配置细节。

现在快速发展到今天，Micro ORM似乎正在赢得更多开发人员的支持，我想知道为什么我们似乎在整个内联sql主题上都掉头了。

我必须承认，我确实喜欢没有ORM配置文件的想法，并且能够以更优化的方式编写查询，但是感觉就像我向诸如SQL注入之类的旧漏洞敞开了怀抱，而且我也将自己束缚于一个数据库引擎，因此，如果我希望我的软件支持多个数据库引擎，则需要做更多的字符串黑客攻击，这似乎开始使代码变得不可读且更脆弱。（就在有人提到它之前，我知道您可以在大多数micro orms中使用基于参数的参数，这在大多数情况下都可以防止sql注入）

那么人们对此事有何看法？在这种情况下，我将Dapper用作微型ORM，在这种情况下将NHibernate用作常规ORM，但是在每个领域中的大多数情况都非常相似。

我所说的内联SQL是源代码中的SQL字符串。曾经有过关于源代码中SQL字符串的设计争论，这有损于逻辑的基本意图，这就是为什么静态类型的linq样式查询如此流行的原因，它仍然仅是一种语言，但是在一页中说C＃和Sql现在，您的原始源代码中混合了2种语言。为了澄清起见，SQL注入只是使用sql字符串的已知问题之一，我已经提到过可以通过基于参数的查询阻止这种情况的发生，但是我着重指出了在源代码中根植SQL查询的其他问题，例如缺少DB Vendor抽象以及在基于字符串的查询上丢失任何级别的编译时错误捕获功能，这些都是我们设法通过ORM的高级查询功能来解决的问题，

因此，我不太关注各个突出的问题，而更全局的是，由于大多数Micro ORM使用这种机制，现在再次将SQL字符串直接再次包含在源代码中变得越来越容易被接受。

这是一个类似的问题，它具有一些不同的观点，尽管更多是关于没有微规范上下文的内联sql：

/programming/5303746/is-inline-sql-hard-coding

您所说的“内联SQL”实际上应该称为“不带参数化的字符串连接”，并且不必为了安全地使用Micro ORM而这样做。

考虑以下Dapper示例：

string sql = "SELECT * from user_profile WHERE FirstName LIKE @name;";
var result = connection.Query<Profile>(sql, new {name = "%"+name+"%"});

即使正在进行字符串连接，它也已完全参数化。看到@符号了吗？

还是这个例子：

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", 
          new { Age = (int?)null, Id = guid });

这大致等效于以下ADO.NET代码：

List<Dog> dog = new List<Dog>();
using(var cmd = connection.CreateCommand()) {
    cmd.CommandText = "select Age = @Age, Id = @Id";
    cmd.Parameters.AddWithValue("Age", DBNull.Value);
    cmd.Parameters.AddWithValue("Id", guid);
    using(var reader = cmd.ExecuteReader()) {
        while(reader.Read()) {
            int age = reader.ReadInt32("Age");
            int id = reader.ReadInt32("Id");
            dog.Add(new Dog { Age = age, Id = id });
        }
    }
}

如果您需要的灵活性更大，Dapper提供了SQL模板和一个AddDynamicParms()函数。所有SQL注入安全。

那么为什么要首先使用SQL字符串呢？

嗯，出于相同的原因，您将在任何其他ORM中使用自定义SQL。也许ORM是代码生成次优的SQL，您需要对其进行优化。也许您想做一些本机上很难在ORM中完成的事情，例如UNION。或者，也许您只是想避免生成所有那些代理类的复杂性。

如果您确实不想在Dapper中为每个CRUD方法编写SQL字符串（谁这样做），则可以使用以下库：

https://github.com/ericdc1/Dapper.SimpleCRUD/

这将为您提供极其简单明了的CRUD，同时仍为您提供手写SQL语句的灵活性。记住，上面的ADO.NET示例是每个人在ORM出现之前所做的方式。Dapper只是薄薄的单板。

我喜欢sql，无法忍受看到它被字符串文字砍掉了，所以我写了一个VS扩展名，让您在c＃项目中使用真实的sql文件。在自己的文件中编辑sql可以使您智能化列和表，语法验证，测试执行，执行计划以及其他内容。保存文件时，我的扩展程序会生成c＃包装器类，因此您永远不必编写一行连接代码，命令代码，参数或读取器代码。因为没有其他方法，所以对查询都进行了参数化，并且已经生成了用于单元测试的存储库和POCO，并对输入参数和结果进行了智能感知。

而且我还免费提供了牛排刀……当专家需要来重新开发开发人员的sql时，她正在查看一个真正的sql文件，并且不需要接触任何C＃。当她返回并整理数据库时，删除了一些列，对缺失列的引用由于c＃中的编译错误而直接跳出。数据库就像解决方案中的另一个可以入侵的项目一样，它的界面可以在代码中发现。如果解决方案可以编译，则说明所有查询都在工作。没有由于无效的转换，无效的列名或无效查询而导致的运行时错误。

回顾我们仍在使用的dapper，我不敢相信在2016年这是数据访问中最酷的事情。运行时msil生成在所有情况下都是聪明的，但是所有错误都是运行时错误，并且字符串操作（如出于任何其他目的的字符串操作）是耗时，易碎且容易出错的。不得不在POCO中重复输入列名，这是多么干燥的事情，您必须手工编写和维护这些列名。

所以你去了。如果您想了解一下一个闻所未闻的数据访问技术，而这是闻所未闻的开发人员在业余时间（带着一个年幼的孩子和许多其他爱好）工作的地方，那就在这里。

通过参数化查询以及存储库设计模式，您可以完全控制查询内容以防止注入攻击。在这种情况下，内联SQL除了对于大型和复杂查询的可读性外，不是什么问题，无论如何应将其放在存储过程中。