既然我们拥有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