3
Micro ORMが導入された今、インラインSQLは依然として悪い習慣に分類されていますか？
これは少し自由な質問ですが、インラインSQLスクリプトが標準である世界で育ったので、私はいくつかの意見が欲しかったので、SQLインジェクションに基づく問題と、SQLがどれほど脆弱であるかをすべて非常に認識しましたあらゆる場所で文字列操作を行います。 次に、クエリをORMに説明し、独自のSQLを生成させるORMの夜明けが来ました。多くの場合、これは最適ではありませんが、安全で簡単です。ORMまたはデータベース抽象化レイヤーのもう1つの良い点は、SQLがデータベースエンジンを念頭に置いて生成されたため、Hibernate / NhibernateをMSSQL、MYSQLで使用でき、コードが変更されることはなく、構成の詳細だけであったことです。 マイクロORMがより多くの開発者を獲得しているように見える今日に早送りします。なぜインラインSQLの主題全体でU-Turnを採用したように見えるのか疑問に思いました。 ORM構成ファイルがなく、より最適な方法でクエリを作成できるというアイデアが好きであることを認めなければなりませんが、SQLインジェクションなどの古い脆弱性に立ち向かうように感じており、データベースエンジンが1つなので、ソフトウェアで複数のデータベースエンジンをサポートしたい場合は、文字列のハッカーをさらに実行する必要があり、コードが判読不能で壊れやすくなります。（誰かが言及する前に、ほとんどの場合、SQLインジェクションからの保護を提供するほとんどのマイクロオームでパラメータベースの引数を使用できることを知っています） それでは、この種のことについての人々の意見は何ですか？この例ではDapperをMicro ORMとして使用し、NHibernateをこのシナリオでは通常のORMとして使用していますが、各フィールドのほとんどは非常によく似ています。 私の用語インラインSQLソースコード内のSQL文字列です。以前は、ロジックの基本的な意図を損なうソースコードのSQL文字列をめぐる設計上の議論がありました。そのため、静的に型付けされたlinqスタイルクエリが非常に人気があり、まだ1つの言語でしたが、1つのページでC＃とSql 2つの言語が生のソースコードに混ざりました。明確にするために、SQLインジェクションはsql文字列の使用に関する既知の問題の1つにすぎません。パラメーターベースのクエリでこれが発生するのを防ぐことができることは既に述べましたが、次のようなソースコードにSQLクエリを埋め込むことに関する他の問題を強調しますDBベンダーの抽象化の欠如、および文字列ベースのクエリでのコンパイル時エラーキャプチャのレベルの喪失、これらはすべて、より高いレベルのクエリ機能を備えたORMの夜明けを回避することができた問題です。 したがって、私は個々の強調された問題にはあまり焦点を当てておらず、より大局的には、ほとんどのマイクロORMがこのメカニズムを使用するため、ソースコードに直接SQL文字列を含めることがより受け入れられるようになりました。 micro ormコンテキストのないインラインSQLの詳細ですが、いくつかの異なる視点を持つ同様の質問があります。 https://stackoverflow.com/questions/5303746/is-inline-sql-hard-coding