ORMを使用しない正当な理由はありますか？[閉まっている]

見習い期間中、NHibernateを使用して、主に自分でコーディングおよび設計したいくつかの小さなプロジェクトを使用しました。さて、いくつかのより大きなプロジェクトを始める前に、データアクセスを設計する方法とORMレイヤーを使用するかどうかについての議論が生じました。私はまだ実習生であり、自分自身をエンタープライズプログラミングの初心者と見なしているため、データベースにオブジェクトリレーショナルマッパーを使用すると、開発を大幅に容易にできるという私の考えを実際に押し付けようとはしませんでした。開発チームの他のコーダーは私よりもはるかに経験が豊富なので、私は彼らが言うことだけをやると思います。:-)

ただし、NHibernateまたは同様のプロジェクトを使用しない2つの主な理由を完全には理解していません。

1. SQLクエリを使用して自分のデータアクセスオブジェクトを作成し、それらのクエリをMicrosoft SQL Server Management Studioからコピーするだけです。
2. ORMのデバッグは難しい場合があります。

したがって、もちろん、多数のSELECTsなどを使用してデータアクセスレイヤーを構築することもできますが、ここでは、自動結合、遅延読み込みプロキシクラス、およびテーブルが新しい列を取得するか列が名前が変更されました。（多数のSELECT、INSERTおよびUPDATEクエリの更新と、マッピング構成の更新、およびおそらくビジネスクラスとDTOのリファクタリング）。

また、フレームワークをよく知らない場合、NHibernateを使用して予期しない問題が発生する可能性があります。たとえば、文字列の長さが自動的に検証されるように設定したTable.hbm.xmlを信頼する場合などです。ただし、「単純な」SqlConnectionクエリベースのデータアクセスレイヤーに同様のバグがあることも想像できます。

最後に、上記の議論は、重要なデータベースベースのエンタープライズアプリケーションにORMを利用しないことの本当に正当な理由ですか？彼ら/私が逃したかもしれない他の議論はおそらくありますか？

（これは、チームワークを必要とする最初の「大きな」.NET / C＃ベースのアプリケーションのようなものだと思うことを追加する必要があります。ユニットテストや継続的な統合など、スタックオーバーフローではかなり正常と見なされる良い習慣はありません。 -ここまで存在します。）

近年、ORMの爆発的な成長があり、経験豊富な同僚は、「データベースコールはすべてストアドプロシージャを介して実行する必要がある」という考え方をまだ考えているかもしれません。

ORMがデバッグを困難にするのはなぜですか？ストアドプロシージャからのものでも、ORMからのものでも、同じ結果が得られます。

私がORMで考えることができる唯一の本当の不利益は、セキュリティモデルの柔軟性が少し低いことだと思います。

編集：私はあなたの質問をもう一度読んだだけです、そしてそれはそれらがコピーされ、クエリをインラインSQLに貼り付けているようです。これにより、セキュリティモデルはORMと同じになるため、ORMよりもこのアプローチに勝る利点はまったくありません。パラメータ化されていないクエリを使用している場合、実際にはセキュリティ上のリスクがあります。

簡単な答えは「はい」です。本当に正当な理由があります。実際には、ORMを使用できない場合があります。

適切な例として、私は大企業の金融機関で働いており、多くのセキュリティガイドラインに従う必要があります。私たちに課せられている規則や規制を満たすために、監査に合格する唯一の方法は、ストアドプロシージャ内でデータアクセスを維持することです。今では、それは単なるばかげていると言う人もいるかもしれませんが、正直なところ、そうではありません。ORMツールを使用するということは、ツール/開発者が望むものを何でも挿入、選択、更新、または削除できることを意味します。ストアドプロシージャは、特にクライアントデータを処理する環境で、より多くのセキュリティを提供します。これが考慮すべき最大の理由だと思います。セキュリティ。

ORMのスイートスポット

ORMは、該当する場合にクエリの95％以上を自動化するのに役立ちます。それらの強みは、強力なオブジェクトモデルアーキテクチャを備えたアプリケーションと、そのオブジェクトモデルでうまく機能するデータベースがあることです。新しいビルドを行っていて、チームで強力なモデリングスキルを持っている場合は、ORMでおそらく良い結果が得られます。

手作業で行う方がよいクエリがいくつかあるかもしれません。この場合、これを処理するためにいくつかのストアドプロシージャを書くことを恐れないでください。アプリを複数のDBMSプラットフォームに移植するつもりでも、データベースに依存するコードは少数です。アプリケーションをサポートする予定のすべてのプラットフォームでアプリケーションをテストする必要があることを念頭に置いて、一部のストアドプロシージャの移植作業を少し追加しても、TCOに大きな違いは生じません。最初の概算では、98％の移植性は100％の移植性と同じくらい優れており、ORMの制限を回避するための複雑なソリューションやパフォーマンスの低いソリューションよりもはるかに優れています。

前者のアプローチが非常に大規模な（スタッフ数百年の）J2EEプロジェクトでうまく機能するのを見てきました。

ORMが最適でない場合

他のケースでは、ORMよりもアプリケーションに適したアプローチがある場合があります。Fowler's Patterns of Enterprise Application Architectureには、データアクセスパターンに関するセクションがあり、これに対するさまざまなアプローチをカタログ化する上で非常に優れています。ORMが適用できない状況について私が見た例は次のとおりです。

• ストアドプロシージャの実質的なレガシーコードベースを使用するアプリケーションでは、機能指向（機能言語と混同しないでください）のデータアクセスレイヤーを使用して、既存のsprocをラップすることができます。これは、既存の（したがってテストおよびデバッグされた）データアクセスレイヤーとデータベース設計を再利用します。これは、多くの場合、かなりの開発とテストのかなりの労力を表し、データを新しいデータベースモデルに移行する必要がなくなります。これは、多くの場合、レガシーPL / SQLコードベースにJavaレイヤーをラップする、またはリッチクライアントVB、Powerbuilder、またはDelphiアプリをWebインターフェイスでターゲット変更するのに非常に良い方法です。

• バリエーションとは、必ずしもORマッピングに適していないデータモデルを継承する場合です。（たとえば）外部インターフェースからデータを入力または抽出するインターフェースを作成している場合は、データベースを直接使用するほうがよいでしょう。

• 特に2フェーズコミットで複雑な分散トランザクションを使用している場合は、システム間データの整合性が重要な金融アプリケーションまたはその他のタイプのシステム。ORMがサポートできるよりも優れたトランザクションのマイクロ管理が必要になる場合があります。

• データベースアクセスを実際に調整したい高性能アプリケーション。この場合、より低いレベルで作業することが望ましい場合があります。

• ADO.Netのような既存のデータアクセスメカニズムを使用していて「十分に良い」状況で、プラットフォームを適切に操作する状況は、ORMがもたらすよりも大きなメリットがあります。

• データが単なるデータの場合もあります。たとえば、アプリケーションが「オブジェクト」ではなく「トランザクション」を処理していて、これがドメインの賢明なビューである場合があります。この例としては、構成可能な分析フィールドを持つトランザクションがある財務パッケージがあります。アプリケーション自体はOOプラットフォームで構築されている場合がありますが、単一のビジネスドメインモデルに関連付けられておらず、GLコード、アカウント、ドキュメントタイプ、および6ダース以上の分析フィールドを認識していません。この場合、アプリケーションはビジネスドメインモデル自体を認識せず、オブジェクトモデル（元帳構造自体以外）はアプリケーションに関連しません。

まず、ORMを使用しても、コードをテストしやすくなるわけではありません。また、継続的インテグレーションのシーンで利点が得られるとは限りません。

私の経験では、ORMを使用すると開発の速度を上げることができますが、対処する必要がある最大の問題は次のとおりです。

1. コードをテストする
2. コードの保守

これらの解決策は次のとおりです。

1. コードをテスト可能にする（SOLIDの原則を使用）
2. 可能な限り多くのコードの自動テストを作成する
3. 自動テストをできるだけ頻繁に実行する

あなたの質問に来ると、あなたが挙げた2つの異議は何よりも無知のように見えます。

手作業でSELECTクエリを記述できない（これが、コピーと貼り付けが必要な理由だと思います）ことは、SQLトレーニングが緊急に必要であることを示しているようです。

ORMを使用しない理由は2つあります。

1. 会社の方針で固く禁じられています（その場合はどこか別の場所で働きます）
2. プロジェクトは非常にデータ集約的であり、ベンダー固有のソリューション（BulkInsertなど）を使用することがより理にかなっています。

ORM（特にNHibernate）に関する通常の払い戻しは次のとおりです。

1. 速度

   ORMの使用が手動でコード化されたデータアクセスよりも遅くなる理由はありません。実際、キャッシュと最適化が組み込まれているため、処理が速くなります。優れたORMは、スキーマを最適化できる繰り返し可能なクエリのセットを生成します。優れたORMは、さまざまなフェッチ戦略を使用して関連データを効率的に取得することもできます。

2. 複雑

   複雑さに関しては、ORMを使用するとコードが少なくなるため、一般に複雑さが少なくなります。手書きの（またはコード生成された）データアクセスを使用する多くの人々は、「低レベル」のデータアクセスライブラリ（ADO.Netのヘルパーメソッドの記述など）を介して独自のフレームワークを記述していることに気づきます。これらはより複雑に相当し、さらに悪いことに、十分に文書化されたり、十分にテストされたりすることはほとんどありません。
   特にNHibernateに注目している場合、Fluent NHibernateやLinq To NHibernateなどのツールも学習曲線を和らげます。

ORMの議論全体について私を驚かせたのは、ORMを使用するのが難しい/遅い/何でも、Linq To Sqlまたは型付きデータセットを使用して満足している非常に同じ人々であると主張する同じ人々です。Linq To Sqlは正しい方向への大きな一歩ですが、いくつかのオープンソースORMが存在する場所からまだ数年遅れています。ただし、型付きデータセットとLinq To Sqlの両方のフレームワークは依然として非常に複雑であり、それらを使用して（Table = Class）+（基本的なCRUD）から離れるのは非常に困難です。

私のアドバイスは、1日の終わりにORMを取得できない場合、データアクセスが残りのコードから分離されていることを確認し、Gang Of Fourのアドバイスに従ってコーディングすることです。インターフェース。また、依存関係注入フレームワークを取得して、関連付けを行います。

（暴言はどうですか？）

HibernateのようなORMツールが神からの送信である一般的な問題にはさまざまなものがあります。私はあなたのプロジェクトについてそれがどれであるかを知るのに十分なほど知りません。

Hibernateの強みの1つは、3度しか話せないことです。すべてのプロパティは、クラス、.hbm.xmlファイル、およびデータベースで言及されます。SQLクエリでは、プロパティはクラス、データベース、選択ステートメント、挿入ステートメント、更新ステートメント、削除ステートメント、およびSQLクエリをサポートするすべてのマーシャリングコードとアンマーシャリングコードにあります。これは乱雑に速くなります。一方、あなたはそれがどのように機能するか知っています。デバッグできます。サードパーティ製ツールの腸に埋もれているのではなく、独自の永続化レイヤーで問題なく動作します。

Hibernateは、SpolskyのLeaky Abstractionsの法則のポスターの子になる可能性があります。打たれた道を少し離れて、あなたはツールの深い内部の仕組みを知る必要があります。SQLを数分で修正できるとわかっている場合は非常に煩わしいかもしれませんが、代わりに、Dangツールを使用して妥当なSQLを生成しようと何時間も費やしています。デバッグは時には悪夢ですが、そこに行ったことがない人を納得させることは困難です。

編集：NHibernateについて振り向かれる予定がなく、SQLクエリを制御したい場合は、iBatis.NETを調べてください。

編集2：しかし、ここで大きな赤い旗があります：「ユニットテストや継続的統合など、Stack Overflowではかなり正常であると見なされているグッドプラクティスは、これまでここには存在しません。」では、これらの「経験豊富な」開発者は、開発で何を経験したのでしょうか。彼らの仕事の安全は？あなたはその分野に特に興味がない人々の中にいるように思えるので、彼らにあなたの興味を殺させないでください。あなたはバランスを保つ必要があります。戦いを立てます。

私はORMを使用しないことが非常に成功した1つのプロジェクトに取り組みました。それはプロジェクトでした

1. 最初から水平方向に拡大縮小する必要があった
2. 迅速に開発する必要があった
3. 比較的単純なドメインモデルがあった

NHibernateを水平分割構造で機能させるのにかかる時間は、分割スキームを認識している超シンプルなデータマッパーを開発するのにかかる時間よりもはるかに長くなっていました...

したがって、私がORMに取り組んだプロジェクトの90％では、非常に貴重な助けになっています。しかし、ORMを使用しないことが最善であると考える非常に特殊な状況があります。

最初に、ORMは適切に統合されている場合、開発ライフを容易にすることができますが、ORMが実際に指定された要件と目標の達成を妨げる可能性があるいくつかの問題があります。

パフォーマンス要件が厳しいシステムを設計する場合、システムのパフォーマンスを向上させる方法を見つけることがしばしば求められることがわかりました。多くの場合、書き込みパフォーマンスプロファイルが重いソリューションが得られます（つまり、データの読み取りよりもデータの書き込みが多いということです）。このような場合は、パフォーマンス目標（OLAPではなくOLTP）に到達するために、データベースプラットフォームが提供する機能を利用したいと考えています。したがって、SQL Serverを使用していて、書き込むデータが多いことがわかっている場合は、なぜバルク挿入を使用しないのでしょうか。まあ、すでにお気づきのように、ほとんどのORMS（単一のものでも）一括挿入のようなプラットフォーム固有の利点を利用することができません。

ORMとORM以外の手法を組み合わせることができることを知っておく必要があります。私は、ORMが要件をサポートできない少数のエッジケースがあり、それらのケースに対してそれらを回避する必要があることを発見しました。

50000000レコードを更新する必要がある場合。フラグなどを設定します。

ストアドプロシージャやネイティブSQLコマンドを呼び出さずに、ORM を使用してこれを試してください。

Update 1：いくつかのフィールドのみを含む1つのレコードを取得してみてください。（非常に「広い」テーブルがある場合）。またはスカラーの結果。ORMもこれを嫌います。

更新2：EF 5.0ベータはバッチ更新を約束しているようですが、これは非常にホットなニュースです（2012年1月）。

重要なデータベースベースのエンタープライズアプリケーションの場合、ORMを使用しないことには正当な理由はありません。

脇の機能：

• ORMを使用しないことで、重要なリソースを持つ大規模なコミュニティや企業によってすでに繰り返し解決されている問題を解決できます。
• ORMを使用することにより、データアクセスレイヤーのコア部分は、そのコミュニティまたは会社のデバッグ作業から利益を得ます。

議論にいくつかの視点を置くために、ADO.NETを使用することと、表形式のデータストリームを自分で解析するコードを作成することの利点を考慮してください。

ORMを使用してORMに対する開発者の軽蔑を正当化する方法についての無知を見てきました。例：熱心な読み込み（私が気付かなかった何か）顧客とそのすべての注文、およびそれらすべての注文詳細項目を取得したいとします。遅延読み込みのみに依存している場合、「ORMは遅い」という意見でORMの経験から離れることになります。熱心な読み込みの使い方を習得すると、2行で5行のコードを実行できます。同僚が実装するのに半日かかります。データベースへの1つのクエリと結果をオブジェクトの階層にバインドします。もう1つの例は、ページングを実装するためにSQLクエリを手動で作成する手間です。

ORMを使用する場合の例外は、そのアプリケーションが、特別なビジネスロジックの抽象化を適用するように設計され、複数のプロジェクトで再利用できるように設計されたORMフレームワークである場合です。ただし、そうであっても、これらの抽象化で既存のORMを拡張することで、より迅速に採用することができます。

上級チームのメンバーの経験がコンピューターサイエンスの進化とは逆の方向にあなたを引きずらせないようにしてください。私は23年間専門的に開発してきましたが、定数の1つはオールドスクールによる新しいものに対する軽蔑です。ORMはC言語がアセンブリするのと同じようにSQLに対するものであり、C ++およびC＃に相当するものが進んでいることに疑いはありません。1行の新しいコードは、20行の古いコードに相当します。

おそらく、より大きなシステムで作業するときは、ORMの代わりにCodeSmithのようなコードジェネレーターツールを使用できると思います...最近これを見つけました：SQL Serverストアドプロシージャを生成し、ビジネスエンティティ、マッパー、ゲートウェイを生成するCooperator Framework、 lazyloadとC＃でのすべてのこと...それをチェックしてください...それはここアルゼンチンのチームによって書かれました...

データアクセスレイヤー全体のコーディングとORMの使用の中間だと思います...

個人的に、私は（最近まで）ORMを使用することに反対しており、すべてのSQLコマンドをカプセル化するデータアクセスレイヤーを書くことに慣れてきました。ORMに対する主な反対点は、ORM実装が正確に正しいSQLを作成することを信頼していなかったことです。そして、私がよく見たORM（主にPHPライブラリー）から判断すると、私は完全に正しかったと思います。

今、私のWeb開発のほとんどはDjangoを使用しており、含まれているORMは本当に便利であることがわかりました。データモデルは最初に用語で表現され、後でSQLで表現されるだけなので、私のニーズに完全に対応します。それを超えるのはそれほど難しくなく、手書きのSQLで補足する必要があると私は確信しています。CRUDへのアクセスは十分以上です。

NHibernateについては知りません。しかし、私はそれがあなたが必要とするもののほとんどにとっても「十分」であると思います。しかし、他のプログラマーがそれを信頼しない場合、これは、データ関連のすべてのバグの最も疑わしい疑いであり、検証がより退屈になります。

簡単なデータアクセスなど、小さな「自明な」アプリケーションに最初に焦点を当てて、それを職場に徐々に導入してみることができます。しばらくすると、プロトタイプで使用され、置き換えられない可能性があります...

それがOLAPデータベースである場合（たとえば、レポート/分析に使用される静的な読み取り専用データなど）、ORMフレームワークの実装は適切ではありません。代わりに、ストアドプロシージャなど、データベースのネイティブデータアクセス機能を使用することをお勧めします。ORMは、トランザクション（OLTP）システムに適しています。

ORMを使用しない理由はたくさんあると思います。何よりもまず、私は.NET開発者であり、すばらしい.NETフレームワークがすでに提供してくれているものを使い続けたいと思っています。それは私がおそらくそれを必要とするすべてを行います。これを行うことで、より標準的なアプローチを維持できるため、同じプロジェクトで他の開発者が作業していて、そこにあるものを取得して実行できる可能性が高くなります。Microsoftがすでに提供しているデータアクセス機能は非常に豊富で、破棄する必要はありません。

私は10年間プロの開発者であり、数百万ドルを超える非常に成功したプロジェクトを複数リードしており、どのデータベースにも切り替えられるようにする必要があるアプリケーションを書いたことは一度もありません。なぜクライアントにこれを行わせたいのですか？慎重に計画し、必要なものに適したデータベースを選択して、それを使用してください。個人的には、SQL Serverは、私が今までに必要とするあらゆることを実行できました。それは簡単で、うまくいきます。最大10 GBのデータをサポートする無料バージョンもあります。ああ、それは.NETで素晴らしい働きをします。

最近、ORMをデータレイヤーとして使用するいくつかのプロジェクトに取り掛かる必要がありました。それは悪いことだと思いますし、理由もなく使用法を学ぶ必要がありました。お客様がデータベースを変更する必要があっためったにない状況では、ORMプロバイダーを騙して費やすよりも短い時間でデータレイヤー全体を簡単に作り直すことができたでしょう。

正直なところ、ORMの実際の用途は1つだと思います。SAPのようなアプリケーションを構築する場合、複数のデータベースで実行する機能が本当に必要です。それ以外の場合は、ソリューションプロバイダーとして、このアプリケーションがこのデータベースで実行するように設計されていることをクライアントに伝えます。再び、10年と無数のアプリケーションの後、これは決して問題になりませんでした。

それ以外の場合、私はORMがあまり理解していない開発者向けであると思います。また、アプリで使用するサードパーティのツールが優れているほど、アプリはより優れたものになると思います。私はこのようなことを熱心なオタクに任せますが、その間、より優れたソフトウェアを開発しているので、どの開発者も気にせずすぐに生産性を上げることができます。

ランタイムパフォーマンスは私が考えることができる唯一の本当のマイナス面ですが、ORMが開発/テスト/その他を節約する時間の公平なトレードオフ以上だと思います。また、ほとんどの場合、データのボトルネックを特定し、オブジェクト構造を変更してより効率的にすることができます。

私は以前にHibernateを使用したことがありませんが、いくつかの「既製」のORMソリューションで気付いたことの1つは、柔軟性の欠如です。これはあなたがどちらに行くか、そしてあなたがそれをどうする必要があるかによります。

気になるORMには2つの側面があります。まず、それらは他の誰かによって書かれたコードであり、時にはクローズドソース、時にはオープンソースですが、スコープは巨大です。次に、データをコピーします。

最初の問題は2つの問題を引き起こします。あなたは部外者のコードに依存しています。私たちは皆これを行いますが、そうするための選択は軽く取られるべきではありません。そして、それがあなたが必要とすることをしない場合はどうなりますか？いつこれを発見しますか？ORMが描画するボックスの内側に住んでいます。

2番目の問題は、2フェーズコミットの1つです。リレーショナルデータベースをオブジェクトモデルにコピーしています。オブジェクトモデルを変更すると、データベースが更新されます。これは2フェーズコミットであり、デバッグが最も簡単なことではありません。

ORMの欠点のリストについては、この読みをお勧めします。

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

私自身にとって、私が作成したほとんどのアプリケーションにORMが非常に役立つことがわかりました！

/ Asger

私がHibernateで経験したことは、そのセマンティクスが微妙であり、問​​題がある場合、内部で何が問題になっているのかを理解するのが少し難しいことです。友人から、多くの場合、Criteriaで始まり、もう少し柔軟性が必要で、HQLが必要であり、結局、生のSQLが必要であることに気付きました（たとえば、HibernateにはユニオンAFAIKがありません）。

また、ORMを使用すると、既存のマッピング/モデルを使いすぎてしまいがちです。そのため、初期化されていない多くの属性を持つオブジェクトが存在します。したがって、クエリの後、トランザクション内でHibernateは追加のデータフェッチを実行し、これにより速度が低下する可能性があります。また、残念なことに、休止状態のモデルオブジェクトがビューアーキテクチャレイヤーにリークされ、LazyInitializationExceptionsが発生することがあります。

ORMを使用するには、本当に理解する必要があります。残念ながら、そうではないのに簡単だという印象を簡単に得ます。

それ自体は答えではなく、最近聞いた引用を言い換えたいと思います。「優れたORMはイエティのようなものです。誰もが1つのことについて話しますが、誰もそれを見ません。」

ORMに手を置くときはいつも、そのORMの問題/制限に悩まされています。最後に、はい、それは私が望んでいることを行い、それはそのお粗末なドキュメントのどこかに書かれていましたが、私は私が得ることができないもう1時間を失うことに気づきました。nhibernateを使用し、postgresqlで流暢なnhibernateを使用した人なら誰でも、私が何をしてきたか理解できます。「このコードは私の制御下にない」という絶え間ない感覚は本当にうんざりです。

私は指を指さしたり、悪いことを言ったりはしませんが、CRUDを単一の式で自動化するためだけに何を与えるかについて考え始めました。今日、私はORMの少ないものを使用する必要があると思います。おそらく、最低限のdb操作を可能にするソリューションを作成または検索します。しかし、それは私だけです。このORMアリーナではいくつかの点で問題があると思いますが、それを表現するのに十分なスキルはありません。

ORMを使用することはまだ良い考えだと思います。特にあなたが与える状況を考慮してください。あなたの投稿では、dbアクセス戦略に関しては経験が豊富であるようですが、ORMを使用して紹介します。

＃1には引数はありません。テキストのクエリとハードコーディングをコピーして貼り付けると柔軟性がなくなります。＃2の場合、ほとんどのオームは元の例外をラップし、生成されたクエリのトレースなどを許可するため、ロケットサイエンスのデバッグもできません。

検証に関しては、ORMを使用すると、組み込みの検証に加えて、通常、検証戦略を開発する時間がはるかに容易になります。

独自のフレームワークを作成するのは面倒な場合があり、多くの場合、見落とされます。

編集：もう1つ指摘したいと思います。あなたの会社がORM戦略を採用している場合、それはその価値をさらに高めます。使用と実装のためのガイドラインと実践を開発し、誰もが選択したフレームワークに関する知識をさらに高め、あなたが提起した問題の1つを軽減します。また、状況が発生したときに何が機能し何が機能しないかを学び、最終的には多くの時間と労力を節約します。

すべてのORMは、「良いもの」であっても、ソフトウェアがアプリケーションレイヤーとデータストアの間でデータをやり取りするために使用する基礎となるメカニズムに関連する特定の数の前提条件を備えています。

適度に洗練されたアプリケーションの場合、これらの仮定を回避するには、通常、データをクエリして新しいエンティティを手動でインスタンス化するなど、よりまっすぐなソリューションを書くよりも時間がかかることがわかりました。

特に、マルチカラムキーや、コードをダウンロードしたときにORMから提供された便利な例の範囲外にある中程度に複雑な関係を採用すると、すぐに問題が発生する可能性があります。

特定のタイプのアプリケーション、特にデータベーステーブルが非常に多数あるアプリケーション、または動的に生成されるデータベーステーブルでは、ORMの自動マジックプロセスが役立つ場合があると思います。

それ以外の場合は、ORMで地獄へ。私は今それらを基本的に流行であると考えています。