c# - ORM を使用しない正当な理由はありますか?

Question

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

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

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

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

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

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

(おそらく、これはチームワークを必要とする最初の「大規模な」.NET/C# ベースのアプリケーションのようなものだと思うことを付け加えておく必要があります。単体テストや継続的インテグレーションなど、スタックオーバーフローではごく普通のことと見なされているグッドプラクティスではありません。 -現在までここに存在します。)

score 64 · Accepted Answer

短い答えはイエスです。本当に正当な理由があります。実際のところ、ORM を使用できない場合があります。

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

score 59 · Accepted Answer

ORM のスイートスポット

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

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

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

ORM が最適でない場合

他のケースでは、ORM よりもアプリケーションに適したアプローチがあるかもしれません。Fowler's Patterns of Enterprise Application Architectureには、データアクセスパターンに関するセクションがあり、これに対するさまざまなアプローチをかなりうまく分類しています。ORM が適用されない可能性がある状況について私が見たいくつかの例は次のとおりです。

ストアドプロシージャの実質的なレガシーコードベースを持つアプリケーションでは、機能指向の (関数型言語と混同しないでください) データアクセスレイヤーを使用して、既存の sproc をラップすることができます。これにより、既存の (したがって、テストおよびデバッグされた) データアクセスレイヤーとデータベース設計が再利用されます。これは、多くの場合、かなりの開発およびテスト作業を表し、新しいデータベースモデルにデータを移行する必要がなくなります。多くの場合、Java レイヤーをレガシー PL/SQL コードベースにラップしたり、リッチクライアント VB、Powerbuilder、または Delphi アプリを Web インターフェイスで再ターゲットしたりするのに非常に適した方法です。
バリエーションは、必ずしも OR マッピングに適しているとは限らないデータモデルを継承する場所です。（たとえば）外部インターフェイスからデータを入力または抽出するインターフェイスを作成している場合は、データベースを直接操作する方がよい場合があります。
特に 2 フェーズコミットで複雑な分散トランザクションを使用している場合に、システム間のデータ整合性が重要な金融アプリケーションまたはその他の種類のシステム。ORM がサポートできる以上に、トランザクションを細かく管理する必要がある場合があります。
データベースアクセスを実際に調整する必要がある高性能アプリケーション。この場合、より低いレベルで作業することが望ましい場合があります。
ADO.Net のような既存のデータアクセスメカニズムを使用している状況では、「十分」であり、プラットフォームとうまく連携することは、ORM がもたらすよりも大きなメリットがあります。
データが単なるデータである場合もあります。(たとえば) アプリケーションが「オブジェクト」ではなく「トランザクション」で動作し、これがドメインの賢明なビューである場合があります。この例としては、構成可能な分析フィールドを使用して取引を行う財務パッケージが挙げられます。アプリケーション自体は OO プラットフォーム上に構築されている可能性がありますが、単一のビジネスドメインモデルに関連付けられておらず、GL コード、アカウント、ドキュメントタイプ、および半ダースの分析フィールド以上のものを認識していない可能性があります。この場合、アプリケーションはビジネスドメインモデル自体を認識せず、オブジェクトモデル (元帳構造自体を超える) はアプリケーションに関連しません。

score 38 · Accepted Answer

まず、ORM を使用してもコードのテストが簡単になるわけではなく、継続的インテグレーションのシナリオで必ずしも利点が得られるわけでもありません。

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

コードのテスト
コードのメンテナンス

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

コードをテスト可能にする ( SOLID原則を使用)
できるだけ多くのコードの自動テストを書く
自動テストをできるだけ頻繁に実行する

あなたの質問に来て、あなたがリストした2つの異議は、何よりも無知のように思えます.

手動で SELECT クエリを記述できない (これがコピーアンドペーストが必要な理由だと思います) ということは、SQL トレーニングが緊急に必要であることを示しているようです。

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

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

ORM (特に NHibernate) に関する通常の拒絶は次のとおりです。

スピード

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

複雑さに関しては、ORM を使用するとコードが少なくなり、一般に複雑さが軽減されます。手書き (またはコード生成) のデータアクセスを使用している多くの人は、「低レベル」のデータアクセスライブラリ (ADO.Net のヘルパーメソッドの作成など) に対して独自のフレームワークを作成していることに気付きます。これらはより複雑であり、さらに悪いことに、十分に文書化されたり、十分にテストされたりすることはめったにありません。
特に NHibernate を検討している場合は、Fluent NHibernate や Linq To NHibernate などのツールも学習曲線を緩和します。

ORM の議論全体について私を惹きつけているのは、ORM を使用するのは難しすぎる/遅すぎる/何であれ、Linq To Sql または型付きデータセットを使用して満足している人々とまったく同じ人々であるということです。Linq To Sql は正しい方向への大きな一歩ですが、一部のオープンソース ORM からはまだ何年も遅れています。ただし、型指定されたデータセットと Linq To Sql の両方のフレームワークは依然として非常に複雑であり、それらを使用して (Table=Class) + (basic CRUD) の範囲を超えることは非常に困難です。

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

（暴言はどうですか？）

score 35 · Accepted Answer

Hibernate のような ORM ツールが非常に役立つ一般的な問題は幅広くありますが、それが妨げとなる問題もいくつかあります。私はあなたのプロジェクトについて十分に知りません。

Hibernate の強みの 1 つは、3 回しか発言できないことです。クラス、.hbm.xml ファイル、およびデータベースですべてのプロパティが言及されます。SQL クエリでは、プロパティはクラス、データベース、select ステートメント、insert ステートメント、update ステートメント、delete ステートメント、および SQL クエリをサポートするすべてのマーシャリングおよびアンマーシャリングコードにあります。これはすぐに混乱する可能性があります。一方、あなたはそれがどのように機能するかを知っています。デバッグできます。サードパーティのツールの腸に埋もれているのではなく、独自の永続化レイヤーに問題ありません。

Hibernate は、Spolsky の Leaky Abstractions の法則のポスターになる可能性があります。人里離れた道から少し離れて、ツールの内部の深い仕組みを知る必要があります。SQL を数分で修正できたはずなのに、何時間もかけてツールをだまして合理的な SQL を生成させようとしていると、非常に煩わしくなります。デバッグは時には悪夢ですが、行ったことのない人を説得するのは困難です。

編集: NHibernate について好転するつもりがなく、SQL クエリを制御したい場合は、iBatis.NET を調べることをお勧めします。

EDIT 2: ただし、ここに大きな赤い旗があります。では、これらの「経験豊富な」開発者は、開発においてどのような経験を積んでいるのでしょうか? 彼らの雇用保障？あなたはその分野に特に興味のない人の中にいるように聞こえるかもしれないので、彼らにあなたの興味を殺されないようにしてください. あなたはバランスをとる必要があります。戦いましょう。

score 28 · Accepted Answer

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

なぜ ORM はデバッグを難しくするのでしょうか? ストアドプロシージャまたは ORM のどちらからでも同じ結果が得られます。

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

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

score 13 · Accepted Answer

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

最初から水平にスケーリングする必要がありました
早急に開発する必要があった
比較的単純なドメインモデルを持っていた

水平分割された構造で NHibernate を動作させるのにかかった時間は、私たちの分割スキームを認識する非常に単純なデータマッパーを開発するのにかかった時間よりもはるかに長かったでしょう...

そのため、私が取り組んできたプロジェクトの 90% で、ORM は非常に大きな助けになりました。しかし、ORM を使用しないのが最善であると思われる非常に特殊な状況がいくつかあります。

score 11 · Accepted Answer

最初に、ORM を適切に統合すれば開発作業が楽になることをお伝えしますが、ORM が実際に、指定された要件や目標の達成を妨げる可能性がある問題がいくつかあります。

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

ORM 手法と非 ORM 手法をブレンドできることを知っておく必要があります。ORM が要件をサポートできない少数のエッジケースがあり、それらのケースを回避する必要があることがわかりました。

score 11 · Accepted Answer

重要なデータベースベースのエンタープライズアプリケーションの場合、ORM を使用しないことを正当化することはできません。

特徴はさておき：

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

議論にある程度の見通しを立てるために、ADO.NET を使用することと、表形式のデータストリーム自体を解析するコードを記述することの利点を検討してください。

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

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

上級チームメンバーの経験によって、コンピュータサイエンスの進化とは逆の方向に引きずり込まれないようにしてください。私は 23 年間プロとしてのキャリアを積んできましたが、一貫していることの 1 つは、古い学校による新しいものへの軽蔑です。ORM は、C 言語がアセンブルに対するものであったように、SQL に対するものであり、C++ および C# に相当するものが進行中であることは間違いありません。新しい学校のコードの 1 行は、古い学校の 20 行に相当します。

score 9 · Accepted Answer

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

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

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

更新 2 : EF 5.0 ベータ版ではバッチ更新が約束されているようですが、これは非常にホットなニュースです (2012 年 1 月)

score 8 · Accepted Answer

大規模なシステムで作業する場合は、ORM の代わりにCodeSmith のようなコードジェネレーターツールを使用できると思います... lazyload と C# のすべてのもの...チェックしてください...ここアルゼンチンのチームによって書かれました...

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

score 6 · Accepted Answer

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

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

NHibernate については知りません。しかし、必要なもののほとんどには「十分」だと思います。しかし、他のコーダーがそれを信頼していない場合。データ関連のすべてのバグの主な容疑者になるため、検証がより面倒になります。

単純なデータアクセスなど、小さな「明白な」アプリケーションに最初に焦点を当てて、職場で徐々に導入することを試みることができます。しばらくすると試作品に使われて、取り替えられなくなるかも…。

score 5 · Accepted Answer

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

score 5 · Accepted Answer

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

私はプロの開発者として 10 年間、数百万ドル以上のプロジェクトを率いて成功を収めてきましたが、データベースに切り替える必要のあるアプリケーションを作成したことは一度もありません。なぜクライアントにこれをしてもらいたいのですか？慎重に計画し、必要なものに適したデータベースを選択して、それを使い続けてください。個人的には、SQL Server は私が今まで必要としていたすべてのことを実行できました。それは簡単で、うまく機能します。最大10GBのデータをサポートする無料版もあります. ああ、それは .NET で素晴らしく動作します。

最近、ORM をデータレイヤーとして使用するいくつかのプロジェクトに取り組み始めなければなりませんでした。私はそれが悪いと思います、そして私は何の理由もなく使い方を学ばなければならなかった余分なものです. 非常にまれな状況で、顧客がデータベースを変更する必要があった場合、ORM プロバイダーをだますのに費やした時間よりも短い時間で、データレイヤー全体を簡単に作り直すことができたはずです。

正直なところ、ORM の真の用途が 1 つあります。複数のデータベースで実行する機能が本当に必要な SAP のようなアプリケーションを構築している場合です。それ以外の場合は、ソリューションプロバイダーとして、このアプリケーションはこのデータベースで実行するように設計されているとクライアントに伝えています。繰り返しになりますが、10 年間、数え切れないほどの申請がありましたが、これは一度も問題になったことはありません。

それ以外の場合、ORM は、少ないほど良いことを理解していない開発者向けであり、アプリでクールなサードパーティツールを使用すればするほど、アプリはより優れたものになると考えています。このようなことは根っからの uber オタクに任せておきますが、それまでの間、開発者なら誰でも手に入れてすぐに生産性を高めることができる、より多くの優れたソフトウェアを開発します。

score 4 · Accepted Answer

ORM には気になる点が 2 つあります。まず、それらは他の誰かによって書かれたコードであり、クローズドソースの場合もあれば、オープンソースの場合もありますが、その範囲は膨大です。次に、データをコピーします。

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

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

score 3 · Accepted Answer

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

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

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

score 3 · Accepted Answer

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

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

私自身、私が書いたほとんどのアプリケーションで ORM が非常に便利であることがわかりました。

/アスガー

score 3 · Accepted Answer

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

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

score 2 · Accepted Answer

ORMを使用することはまだ良い考えだと思います。特にあなたが与える状況を考えると。あなたの投稿によると、データベースアクセス戦略に関してはあなたがより経験豊富であると思われます.ORMを使用して育てます。

クエリをコピーして貼り付けたり、テキストにハードコーディングしたりすると柔軟性がなくなるため、#1 には議論の余地がありません。また、#2 については、ほとんどの orm が元の例外をラップし、生成されたクエリをトレースできるようになるため、デバッグもロケット科学ではありません。

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

独自のフレームワークを作成するのは骨が折れる可能性があり、多くの場合見逃されます。

編集：もう1点言いたかった。あなたの会社が ORM 戦略を採用すると、その価値がさらに高まります。使用および実装のためのガイドラインとプラクティスを作成し、選択したフレームワークに関する知識を全員がさらに高め、あなたが提起した問題の 1 つを軽減するからです。また、状況が発生したときに何が機能し、何が機能しないかを学び、最終的には多くの時間と労力を節約できます.

score 1 · Accepted Answer

すべての ORM は、「優れたもの」であっても、ソフトウェアがアプリケーション層とデータストア間でデータをやり取りするために使用する基本的なメカニズムに関連する、一定数の仮定を抱えています。

適度に洗練されたアプリケーションの場合、これらの仮定に対処するには、データのクエリや新しいエンティティの手動インスタンス化などのより単純なソリューションを単純に記述するよりも、通常は時間がかかることがわかりました。

特に、コードをダウンロードしたときに ORM が提供する便利な例の範囲外にある、複数列のキーまたはその他の適度に複雑な関係を使用するとすぐに、問題が発生する可能性があります。

特定のタイプのアプリケーション、特に非常に多数のデータベーステーブルまたは動的に生成されたデータベーステーブルを持つアプリケーションでは、ORM の自動魔法のプロセスが役立つことを認めます。

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

c# - ORM を使用しない正当な理由はありますか?

20 に答える 20

重要なデータベース ベースのエンタープライズ アプリケーションの場合、ORM を使用しないことを正当化することはできません。

Related

Reference

重要なデータベースベースのエンタープライズアプリケーションの場合、ORM を使用しないことを正当化することはできません。