OOD では、オブジェクトのデザインは、そのアイデンティティと動作によって特徴付けられると言われています。
過去に ORM を使用したことがありますが、私の意見では、主な目的はデータを保存/取得する機能を中心に展開しています。つまり、ORM オブジェクトは動作による設計ではなく、データ (つまりデータベース テーブル) です。ケースとポイント: 多くの ORM ツールには、データベース テーブルへのポイント アンド クリック オブジェクト ジェネレーターが付属しています。
オブジェクトが動作によって特徴付けられなくなった場合、私の意見では、オブジェクトのアイデンティティと責任が曖昧になります。その後、オブジェクトが責任によって定義されていない場合、密結合されたクラスと全体的な貧弱な設計に手を貸す可能性があります。
さらに、アプリケーションの設定では、スケーラビリティの問題に向かっていると思います。
私の質問は、ORM は OO 設計に逆効果だと思いますか? おそらく、根底にある問題は、それらがアプリケーション開発に逆効果であるかどうかということでしょう。
優れたデータベース設計の要件と優れたオブジェクト指向設計の要件の間には、よく知られており、しばしば無視されているインピーダンスの不一致があります。ほとんどの開発者（私の経験では）は、このインピーダンスの不一致を理解していないか、気にしません。データベースから始めて、データベースからオブジェクトを生成するのが一般的であるため（逆ではなく）、そうです。永続レイヤーとしては優れていますが、OOの観点からは最適ではないオブジェクトになります。（逆に、オブジェクトモデルからデータベースを生成すると、目を刺したくなります。）
OOの観点からなぜそれらは最適ではないのですか？ORMによって生成されるオブジェクトは、部分的なクラスなどであっても、ビジネスオブジェクトではないためです。ビジネスオブジェクトモデルの動作。ORMオブジェクトは永続性をモデル化します。私はこの区別を議論するために10段落を費やすつもりはありません。これは、ロッキー・ロトカがビジネスオブジェクツと彼のCSLAフレームワークに関する本で非常によくカバーしているものです。CSLAが好きかどうかにかかわらず、彼の議論は確かなものだと思います。
オブジェクトが動作によって特徴付けられなくなった場合、私の意見では、オブジェクトのアイデンティティと責任が曖昧になります。
問題のオブジェクトには、定義された動作としてデータベースの読み取りと書き込みがあります。彼らはそれ以外のものをほとんど持っていません。
状況の現実は非常に単純です。オブジェクト指向はそれ自体が目的ではなく、目的を達成するための手段です。しかし、場合によっては、最終結果の改善にあまり役立たないこともあります。ORM の多くの用途がその好例です。それらは、処理するほとんどのデータに実際の動作を関連付ける必要がない、または関連付けたくない CRUD アプリケーションの何千ものバリエーションです。
アプリケーション自体のコードにデータの「動作」の多く (あるとしても) をエンコードしないことで、アプリケーション全体として柔軟性が得られます。代わりに、UI からデータベースに単純にパススルーし、レポートなどに戻るという「ダム」データを使用したほうがよい場合がよくあります。少し注意すれば、実際の動作がアプリケーションにエンコードされた実際のオブジェクトとしてデータを処理しようとすると、ほとんど一致しないかなりのレベルのユーザー カスタマイズが可能になります。
もちろん、これには別の側面もあります。データの整合性を確保することや、データが適切に使用されていることを確認することが大幅に難しくなる可能性があります。計算で誤って間違ったフィールドを使用するコードを見たことがあります。平方フィート単位のオフィスのサイズではなく、オフィスの数を平均していました。どちらもユーザー定義フィールドで、内容は数値でなければならないというだけでした。アプリケーションは、一方が完全に理にかなっていて、もう一方がまったく理にかなっていないことを知る方法がありませんでした。
ケースとポイント: 多くの OR/M ツールには、データベース テーブルへのポイント アンド クリック オブジェクト ジェネレーターが付属しています。
はい。ただし、オブジェクトに基づいてデータベース テーブルを生成する ORM ソリューションの数は多くないにしても、同等です。
データから始めて、自動生成されたオブジェクトにオブジェクトの動作を強制することを踏みにじると、確かに混乱するかもしれません... しかし、オブジェクトから始めてデータベースを二次層として生成すると、データベースがおそらく最適化されていなくても、はるかに使いやすくなります。
ORM を使用しない言い訳を探している場合は、使用しないでください。個人的には、ORM が優れた機能を発揮する些細なことを実行する何千行ものコードを節約できることに気付きました。
データを動作から分離するシステムでは、まったく逆効果です。
Orm システムは、既存のデータベース テーブルを分析して、お使いの言語でばかげた「オブジェクト」を作成する傾向があります。これらはビジネス行動を含まないため真のオブジェクトではありませんが、人々はこれらの構造を持っているため、それらを使用したいと思う傾向があります。
Ruby on Rails (Active Record) は実際にデータを「ライブ」クラスにバインドします。これははるかに優れています。
私が本当に気に入ったシステムを見たことがありません.ActiveRecordは近いですが、私があまり快適ではないいくつかのルビーのような仮定をしています.最大のものは、デフォルトでパブリックセッターとゲッターを提供することです.
しかし、要約すると、私は多くの優れた OO プログラマーが ORM のせいでめちゃくちゃなコードを書いているのを見てきました。
永続性が動作の不可欠な部分であると主張したい場合を除き、ORM が OO 設計に逆効果であるとは思いません。
私は永続性をビジネス上の行動から切り離します。ORM が生成する任意のオブジェクトにビジネスの動作を自由に追加できます。
また、OO モデルから移行してデータベースを生成する ORM システムも見てきました。
どちらかといえば、ORM は優れたデータベース コードを生成するよりも、優れた OO コードを生成することに偏っていると言えます。
理想的には、成功した ORM は 2 つの世界を橋渡しし、アプリケーション コードはビジネス ドメインの問題解決と実装の観点から優れたものであり、データベース コードとモデルは正規化、パフォーマンス、ETL/レポート/レプリケーションのあらゆる観点から優れたものです。
このタイプのほとんどの質問と同様に、使い方によって異なります。
ORM ツールを使用する主な方法は次のとおりです。
ゼロから始める場合、3 つ目の方法は、オブジェクト モデルからデータを設計することです。(できればベスト)
そうです、データ テーブルでオブジェクトを定義し、それをコード全体で使用すると、OOD を使用せず、設計とメンテナンスの問題が非常に貧弱になります。
ただし、ORM オブジェクトを (ADO の代わりに) データ アクセス ツールとしてのみ使用する場合は、優れた OOD と ORM を一緒に自由に使用できます。確かに、解釈層を構築するにはより多くのコードが必要ですが、古い ADO コードよりも多くのコードを必要とせずに、はるかに優れたプラクティスを実現できます。
私はC＃の観点からこれに答えています。それは私が開発の大部分を行っている場所だからです....
私はあなたの主張を理解していますが、部分クラスを作成する機能を使用すると、任意の動作でオブジェクトを作成でき、OR/M がデータ検索のためにテーブルにもたらす力を得ることができると思います。
私が ORM について見てきたことから、それらは OO の原則に反することはありません - 実際、それらとはかなり直交しています。(情報 - ORM テクノロジの新機能、Java の観点)
私の理由は、ORM を使用すると、クラスのデータ メンバーを永続ストアに格納するのに役立ち、そのストアに結合してそのコードを自分で記述する必要がないからです。データ メンバーを決定し、クラスの動作を記述します。
ORMを悪用してOOの原則を破ることができると思いますが、それは何でもできます。ツールを使用して既存のテーブルから骨格データ クラスを作成することもできますが、それでもメソッドなどを作成することになります。