パフォーマンス不足，あるいは分からないことが多すぎる，といった理由でORM(Object-Relational Mapper)が放棄される場合，その多くは使い方が間違っている – Jimmy Bogard氏は，先日行ったプレゼンテーションで，マッピングやクエリの問題に関して，ORMの正しい使用法と正しくない使用法は何か，ということを詳しく論じた。
AutoMapperの開発者であり，Microsoft MVPでもある氏は，ORMについて，アプリケーションがデータベースからデータを取り出したり，あるいはその逆を行ったりするツールだと説明する。これらは簡単そうに見えても，実際には非常に複雑な問題なのだ。
氏の言及するマップ問題のひとつは，既存のデータベースからコードが自動生成するタイプのマッピングコードである。これは一見便利に思えても，大抵はリレーションや余分なナビゲーションが多すぎて，パフォーマンス上の問題を発生させることになる。代わりに氏は，既存データベースに対してもコードファーストを使用して，必要に応じてマッピングやリレーションを追加するようにしている。
氏の経験では，ORMを利用する開発者がもっとも不満なのが，レイジー(Lazy)ローディングあるいはSelect N+1ローディングと呼ばれる機能だ。ORMではこれらの機能を使用して，必要な時にデータを読み込むのではなく，複雑なモデルの下ですべてのデータを遅延ローディングする，問題になるのは，プロパティの読み込み時やコレクションのループ時などに，データベースが何回もコールされる可能性があることだ。氏は可能な限りイーガー(Eager)フェッチを使用して，必要なデータをすべてひとつの要求で読み込むようにしている。
リポジトリは，氏が誤ったアイデアと考えているパターンだ。 DDDのオリジナル本で紹介されたリポジトリは，データストア上のコレクション的なインターフェースとして考えられていた。それがORM上では，ORM特有の機能を隠ぺいするためのファサードパターンに変容してしまっている，というのが氏の意見だ。この場合リポジトリは，実際のORMのデリケーション実装に対する，単なるダムインターフェースに過ぎない。ORMを有効に利用するためには，隠ぺいされた機能を利用する必要があるため，実装の詳細がアプリケーションから参照されることになってしまう。結果としてリポジトリは，ORM上の手の込んだラッパ以上のものではなくなってしまうのだ。
リポジトリに代えて氏は，それぞれのデータ要求をコマンドまたはクエリとしてモデル化して，個々の要求を処理するすべてのコードをひとつのクラス内に移動する，という方法を利用している。それによって，例えば，新しいデータアクセス方法を採用するなどの変更は，特定のクラスにカプセル化されることになる。
SQLフリーという考え方も誤ったアイデアだ，と氏は言う。ORMはSQLの知識を不要にするためのものではない。ORM上で動作するビジネスクリティカルなシステムにおいては，どのようなSQLが実行されているか，どのように動作しているかを知っておくことが重要なのだ。