ORMはアンチパターンですか？
私はORMとその長所と短所について同僚と非常に刺激的で興味深い議論を交わしました。私の意見では、ORMは非常にまれなケースでのみ役立ちます。少なくとも私の経験では。
しかし、私は現時点で自分の主張を列挙したくありません。 ORMについてどう思いますか？長所と短所は何ですか？
オブジェクト指向の角度からリレーショナルデータベースにアプローチしようとすると、かなり大きな多様な概念的および技術的な問題が発生します。これらの問題はまとめてオブジェクトリレーショナルインピーダンスミスマッチとして知られており、 関連するWikipediaの記事 は非常に有益です。記事にはかなりの数が記載されていますが、ここではそれらを説明する賢明な方法は見当たりません。一般的な考え方を示すために、これらは次のようにカタログ化されています。
- 不一致
- オブジェクト指向の概念
- データ型の違い
- 構造と完全性の違い
- 操作の違い
- トランザクションの違い
- インピーダンスの不一致を解決する
- 最小化
- 代替アーキテクチャ
- 補償
- コンテンション
- 哲学の違い
時間をかけて記事を読むと、ORMがアンチパターンとして説明されることがあるという事実が実際に避けられないことを理解できると思います。 2つのドメインは非常に異なるので、アンチパターンはドメインの哲学に反するパターンであるという意味で、一方を他方として扱うアプローチはデフォルトでアンチパターンです。
しかし、この用語が本質的に2つの大きく異なるドメイン間のブリッジとして機能するものに適用されるとは思いません。パターンをアンチパターンとしてラベル付けすることは、そのドメイン内でのみ意味があります。したがって、それがアンチパターンであるかどうかの問題は無関係です。
しかし、それは役に立ちますか？はいORMは、世の中で最も有用なアンチパターンの1つです。プロジェクトでデータベースを交換する必要がある実際的な状況にいる場合にのみ、その理由を理解できます。または、同じデータベースの別のバージョンにアップグレードすることもできます。 ORMはそれらの1つであり、実際にそれらを必要とする場合にのみ完全に理解します。
もちろん、すべてが役立つので、ORMは非常に乱用されがちです。どういうわけか、作業しているデータベースに関するすべてを知る必要性に取って代わると思うなら、それは戻ってきてあなたを噛みます。ハード。
最後に、恥ずかしげなく 私のもう1つの回答 を関連させて "ActiveRecordパターンはSOLID設計原則に従っているか/奨励していますか？" 質問。これは、「アンチパターンですか」よりもはるかに関連性の高い質問です。
これは、「パワードリルはアンチパターンですか？」と尋ねるのと同じです。 ORMは私のツールボックスで良い場所を得て、ボイラープレートコードを減らしましたが、必要に応じてカスタムSQLを引き続き使用できます。それがアンチパターンである場合、どのパターンに反しますか？
私の答えは「いいえ」です。人生をずっと簡単にし、コードをより理解しやすくする成熟したORMがたくさんあります。これは、逆に、SQLを理解する必要がないことを意味します。
Martin Fowlerによって最初にパターンと呼ばれ、それ以来ほとんどすべての現代のプログラミング言語に採用されている「アンチパターン」と呼ぶのをためらうでしょう。 （ ActiveRecordに関するWikipediaの記事 を参照してください。）
優れたORMは、プロジェクト内のコードの数を減らし（繰り返しを減らし）、元のコードの量ほどバグと強く関連するものはありません。
ORMは通常、データベースを操作するための最も一般的な使用例を処理するように設計されています。複雑なクエリはまだ明示的に書かれる必要があるかもしれません。しかし、すべてのデータベースの相互作用に対して明示的なクエリを書くことは強くお勧めしません。ほとんどの場合、それは時間の無駄です。
SQLを学習する代わりにORMを使用するのはかなり悪い考えです。生成されるSQLの種類が正確にわからない場合、N + 1の問題と最適化の方法がわからない場合は、間違いなく害が発生します。しかし、私はORMを使用する方がはるかに生産的だと感じています。私はRails ActiveRecordを好みます。これは、データベースが存在しないふりをしようとせず、SQLを記述する必要があるだけでは邪魔になりません。一部の人は信頼するかもしれませんが、心配します彼らが何をしているかについての深い理解なしに、彼らがあまりにも深く見ているイディオム。
私の経験：NHibernateをLinq2NHibernateと共に使用しています。
長所：
- 「マジックストリング」を取り除くか、少なくとも1回だけ配置する場所を提供します。
- OOパラダイムでずっと働くことができます
- コードは簡単ですread
- 上に構築されたコードは変更が簡単です
- これにより、2つの個別のリポジトリを保守することなく、実際のリレーショナルデータベースを交換することができます（めったに行われませんが、必要な場合の大きな利点の1つです）。
短所：
- コードはwriteが難しいため、
- それは十分な抽象化ではありません-それがバックグラウンドで何をしているのかをまだよく理解している必要があります
ほとんどの人が最初に望んでいた約束を果たせないと言います。それがアンチパターンだと言っても誰かを責めることはしません。私の場合、Linq2NHibernateクエリが実際に機能することを確認するために、SQLiteデータベースに対して統合テストを実行する必要があることがわかりました。ですから、実際のリレーショナルデータベースに対して統合テストを実行しているのであれば、「マジックストリング」の問題は解消されます。
新しいプロジェクトを開始する場合、ORMを使用するかどうかはわかりません。私はおそらくそうするでしょうが、確かに言うことはできませんあなたすべきです。それはあなたのプロジェクトにC++またはJava/.NETを選択することの違いのようなものだと思います：あなたはより低いレベルで働くことで得られる柔軟性が必要になるのでしょうか、それともより高いレベルで働きたいのでしょうか？生産的？通常の答えは、あなたと同じくらい高いレベルで作業することです逃げることができるこれは通常、ORMを使用することを意味します。
ORMの長所は、オブジェクト指向の手法を使用してアプリケーションの動作をモデル化できることです。慎重に設計された世界では、ビジネスの言語が開発チームの言語にきちんと出会うアプリケーションの1つのレイヤーがあります。 ORMが賢明に使用されている場合、ORMはそのイネーブラーです。
弱点は、実際にオブジェクト指向プログラミングを実際に受ける人の数がかなり少ないことです。多くの人がスパゲッティやミートボールを記述し、独自の振る舞いがほとんどない高度に結合されたオブジェクトを使用して、実際の振る舞いは恐ろしい8000行の「Service」クラスと「Manager」クラスになり、そのコードは多くの場合、誰もが恐れるほど複雑です彼らは副作用が何であるかを理解することができないのでそれを変えることの。
さらに、多くの人は実際にリレーショナルモデルを理解していません。 ORMは、それらを取得するのに役立ちません。また、リレーショナルモデルを抽象化することによって、それらを支援することもありません。それはあなたが早い段階であなたのドメイン層に集中することを可能にし、そしてあなたがデータベース設計についてあまり心配し始める前にそれを得ることができます。適切に適用された場合、賢明なスキーマ移行ツールの助けを借りて、ORMはコードの負債の増加を防ぐのに役立ちます。
私は、ORMがアプリケーションコードをシンプル、読みやすく、テスト可能に保ち、妥当なパフォーマンスを発揮するアプリケーションを構築しました。また、パターンが悪用され、コードが複雑で、テスト不可能で、遅く、壊れやすいアプリケーションも維持しました。 ORM自体はこれとはほとんど関係がないことがわかります。ただし、アプリケーションドメインのモデル化が不十分な不良コードを作成する代わりに、レガシーエンジニアリングチームがアプリケーションドメインのモデル化が不十分な不良コードと、すべてを無視した不良サービス層コードを作成しました。 ORMが提供できる価値。
ORMはあなたを賢くしませんが、適切な開発者の手に渡れば、より保守可能で高品質なコードにつながる可能性があります。
おそらく答えはあなたの質問の逆にあるでしょう：リレーショナルデータベース以外の何かotherにアプリケーションデータを保存することは良い考えですか？どのような問題を解消し、他にどのような問題を取り上げますか？データ（結合）を簡単に相互参照したり、複数の基準に基づいて必要なレコードをすばやくフィルターで除外したりせずに生活できますか？確かなトランザクションサポートは必要ありませんか（代替案にサポートがない場合）。すべてのアプリケーションが常に一貫した完全なデータストアを必要とするわけではありません。
ここでの実際のアンチパターンは、リレーショナルDBが必要ないときに使用しているのではないかと思います。必要な場合はORMが必要ですが、これは明らかにアンチパターンではありません。
ORMはツールです。すべてのツールと同様に、適切に使用すると、非常にうまく機能します。不適切に使用する場合は、大きなハンマーとダクトテープが必要です。
私が現在取り組んでいるプロジェクトの場合、それは非開発者（正確には機械エンジニア）によって維持されるため、シンプルでわかりやすいものにする必要があります。このグループが開発者を雇う予算を確保するまでには数年かかるでしょう（次期大統領が関与する機関を廃止しないと想定）ので、将来のメンテナンス能力は私たちの考慮事項の主要な要素です。