ORMは反パターンですか？[閉まっている]

ORMとその長所と短所について同僚と非常に刺激的で興味深い議論をしました。私の意見では、ORMは非常にまれな場合にのみ役立ちます。少なくとも私の経験では。

しかし、現時点では自分の主張をリストしたくありません。それでは、ORMについてどう思いますか？長所と短所は何ですか？

オブジェクト指向の角度からリレーショナルデータベースにアプローチしようとすると、かなり大きく多様な概念的および技術的な問題が発生します。これらの困難は、オブジェクトリレーショナルインピーダンスミスマッチとして集合的に知られて おり、関連するウィキペディアの記事は非常に有益です。この記事ではかなりの数を特定していますが、ここでそれらを説明する賢明な方法はありません。一般的なアイデアを示すために、それらは次のようにカタログ化されています。

• 不一致
  • オブジェクト指向の概念
  • データ型の違い
  • 構造と完全性の違い
  • 操作の違い
  • トランザクションの違い
• インピーダンス不整合の解決
  • 最小化
  • 代替アーキテクチャ
  • 補償
• 競合
• 哲学的な違い

記事を読むのに時間をかけると、ORMがアンチパターンとして説明されることがあるという事実が実際には避けられないことを理解できると思います。2つのドメインは非常に異なっているため、アンチパターンはドメインの哲学に反するパターンであるという意味で、一方を他方として扱うアプローチはデフォルトでアンチパターンです。

しかし、この用語は、2つの大きく異なるドメイン間のブリッジとして本質的に機能するものに適用されるとは思わない。アンチパターンとしてパターンにラベルを付けることは、そのドメイン内でのみ意味があります。したがって、それがアンチパターンであるかどうかの問題は無関係です。

しかし、それは便利ですか？はい、ORMは最も有用なアンチパターンの1つです。プロジェクト内のデータベースを交換する必要がある実際的な状況にいる場合にのみ、その理由を理解できます。または、同じデータベースの別のバージョンにアップグレードすることもできます。ORMはそれらの1つであり、実際に必要な場合にのみ完全に理解できます。

もちろん、ORMは有用なものすべてであるため、悪用されやすい傾向があります。どういうわけか、作業中のデータベースに関するすべてを知る必要性に取って代わると思われる場合、戻ってきて噛みつきます。ハード。

最後に、関連する「ActiveRecordパターンはSOLID設計原則に従っている/奨励しているのか？」について、もう1つの答えを恥知らずに差し込もう。私にとっては「アンチパターン」よりもはるかに関連性の高い質問です。

これは、「電動ドリルはアンチパターンですか？」という質問に似ています。ORMは私のツールボックスで良い位置を獲得し、ボイラープレートコードを減らし、必要に応じてカスタムSQLを使用することができます。アンチパターンの場合、どのパターンに反するのでしょうか？

私の答えはノーです。あなたの人生をもっと楽にし、コードをより理解しやすくする成熟したORMがたくさんあります。これは、SQLを理解する必要がないという意味です。まったく逆です。

マーティン・ファウラーによって最初にパターンと呼ばれ、それ以来ほぼすべての現代のプログラミング言語に採用されている「アンチパターン」と呼ぶのをためらうでしょう。（ActiveRecordに関するウィキペディアの記事を参照してください。）

優れたORMを使用すると、プロジェクト内のコードが非常に少なくなり（繰り返しもずっと少なくなります）、元のコードの量ほどバグと強い相関関係はありません。

ORMは通常、データベースを操作するための最も一般的なユースケースを処理するように設計されています。複雑なクエリを明示的に記述する必要がある場合があります。しかし、データベースのやり取りごとに明示的なクエリを書くことは強くお勧めしません。ほとんどの場合、それは時間の無駄です。

SQLを学習する代わりにORMを使用することは、かなり悪い考えです。生成されているSQLの種類を正確に知らない場合、N + 1の問題と最適化の方法を理解していない場合、間違いなく良いよりも害が大きくなります。しかし、私はORMを使用する方がはるかに生産的だと感じています。私はRails ActiveRecordが好きです。RailsActiveRecordはデータベースがないと見せかけようとせず、SQLを書くだけなら邪魔になりません。一部の人々は、自分が何をしているのかを深く理解せずに、あまりにも深く見ているイディオムを信頼するかもしれないと心配しています。

私の経験：NHibernateとLinq2NHibernateを使用しています。

長所：

• 「マジックストリング」を削除するか、少なくとも1回はそれらを配置する場所を提供します。
• それは私がずっとオブジェクト指向のパラダイムで働くことを可能にします
• コードが読みやすい
• 上に構築されたコードは変更が簡単です
• 2つの別個のリポジトリをメンテナンスせずに、実際のリレーショナルデータベースを交換することができます（まれに行われますが、必要な場合は大きな利点の1つです）。

短所：

• コードは書くのが難しいです、なぜなら
• それは十分な抽象化ではありません-あなたはまだそれがバックグラウンドで何をしているのかに親密に精通している必要があります

私は、ほとんどの人が最初に望んでいる約束を守っていないと言います。私はそれがアンチパターンだと言って誰かを責めません。私の場合、Linq2NHibernateクエリが実際に機能することを確認するために、SQLiteデータベースに対して統合テストを行う必要があることがわかりました。とにかく、とにかく実際のリレーショナルデータベースに対して統合テストを実行している場合、その種の「魔法の文字列」の問題を排除します。

新しいプロジェクトを開始する場合、ORMを使用するかどうかはわかりません。おそらくそうするでしょうが、確かにそうすべきだとは言えません。私はそれがあなたのプロジェクトにC ++またはJava / .NETを選択することの違いのようなものだと思います：あなたはあなたがより低いレベルで働くことで得られる柔軟性を必要とするでしょうか、それともあなたはむしろより高いレベルで働き、（おそらく）もっと生産的？通常の答えは、できるだけ高いレベルで働くことです。これは通常、ORMを使用することを意味します。

ORMの長所は、オブジェクト指向の手法を使用してアプリケーションの動作をモデル化できることです。慎重に設計された世界では、ビジネスの言語が開発チームの言語にきちんと合致するアプリケーションの1つの層があります。ORMが賢明に使用される場合、ORMはそれを実現します。

弱点は、実際にオブジェクト指向プログラミングを実際に取得する人の数がかなり少ないことです。多くの人がスパゲッティとミートボールを書きますが、独自の動作をほとんど持たない高度に結合されたオブジェクトを使用し、実際の動作は恐ろしい8000行の「サービス」と「マネージャー」クラスになります。副作用がどうなるかわからないので、それを変更すること。

また、多くの人は実際にリレーショナルモデルを取得していません。ORMは彼らがそれを手に入れるのを助けませんし、リレーショナルモデルを抽象化することによって彼らを助けません。それにより、ドメインレイヤに早く集中し、データベース設計に不安を抱き始める直前にそれを取得できます。賢明なスキーマ移行ツールの助けを借りて適切に適用すれば、ORMはコードの負債の蓄積を防ぐのに役立ちます。

ORMがアプリケーションコードをシンプルで読みやすく、テストしやすくし、適切なパフォーマンスを備えたアプリケーションを構築しました。また、パターンが悪用され、コードが複雑で、テストできず、低速で、脆弱なアプリケーションも保守しました。ORM自体はこれとはほとんど関係がありませんでした。ただし、レガシーエンジニアリングチームは、アプリケーションドメインを貧弱にモデル化した不良コードを書く代わりに、アプリケーションドメインを貧弱にモデル化した不良コードと、すべてを無視した不良サービス層コードを書きました。 ORMが提供できる値。

ORMを使用しても賢くはなりませんが、適切な開発者の手に渡れば、より保守しやすく高品質なコードを作成できます。

おそらく答えは、あなたの質問の逆である：何かにアプリケーションデータを記憶している他のリレーショナルデータベースより良いアイデア？どのような問題を排除しますか？また、他のどのような問題を取り上げますか？データを簡単に相互参照（結合）したり、複数の条件に基づいて必要なレコードをすばやく除外したりすることができませんか？確実なトランザクションサポートは必要ありませんか（代替手段がない場合）。すべてのアプリケーションが常に一貫した完全なデータストアを必要とするわけではありません。

ここでの本当のアンチパターンは、必要のないときにリレーショナルDBを使用しているのではないかと思います。必要な場合はORMが必要です。これは間違いなくアンチパターンではありません。

ORMはツールです。すべてのツールと同様に、適切に使用すると、非常にうまく機能します。不適切に使用する場合は、大きなハンマーとダクトテープが必要です。

私が取り組んでいる現在のプロジェクトの場合、それは開発者ではない人（正確には機械技術者）によって維持されるため、単純でわかりやすいものにする必要があります。このグループが開発者を雇う予算を持つまでには数年かかります（次の大統領が関係機関を廃止しないと仮定）