ICursorの実装でどのような「問題」を解決しようとしているのかわかりません。おそらく、実行しようとしている特定のタスクについてもう少し具体的にする必要があります。ORMの全体的なポイント( AndroidでSQLiteもサポートするこのORMを見逃した)は、コードからRDBMSパラダイム全体を抽象化し、代わりにオブジェクト指向パラダイムを提供することです。
ICursorは、SQLクエリから更新可能な結果セットを返します。つまり、行、結果セット、クエリなどすべてについて知る必要があります。ORMは、オブジェクトまたはオブジェクトのコレクションを返します。1つを更新する場合は、オブジェクトを更新してORMに送り返します。
今、私は、ORMがSQLクエリがうまくいくかもしれない何かをするための最もクリーンなメカニズムを提供しないかもしれない時があることを完全に認めます。たとえば、論理的に「昨日の2番目のシフト中に作成されたすべてのパーツを削除する」場合です。軽量のORMですべてのパーツが提供される場合は、LINQなどを使用して適切な日にフィルタリングし、シフトしてから結果のコレクションを繰り返してそれぞれを削除する必要がありますが、SQLクエリでは、を渡すだけですがDELETE FROM Parts WHERE BornONDate BETWEEN @start AND @end
、それは1つです。あなたが直面するトレードオフの。
場合によっては、ORMはあなたが望むことをするための機能を提供するかもしれません。たとえば、上記のリンク先のOpenNETCF ORMでは、データストアをSQLDataStoreにキャストすると(まだキャストされていない場合)、ExecuteNonQueryメソッドにアクセスして、直接SQLステートメントを渡すことができます。私が言ったように、データベース行を返すことは実際にはアンチテーゼまたはORMであるため、レコードセットを返す手段がまだない場合。
ExecuteNonQueryのようなものを使用することにはいくつかの固有のリスクもあります。バッキングストアを、たとえばSQLiteのようなRDBMSから、オブジェクトデータベースやXMLファイルなどのまったく異なるものに変更したい場合は、SQLクエリをビルドして使用するコードが壊れます。確かにこれは一般的ではないかもしれませんが、コードの移植性と拡張性がレーダー上にある場合は、少なくとも覚えておくべきことがあります。