ORMを使用しない正当な理由はありますか？
私の見習い期間中、私はほとんど自分でコーディングして設計したいくつかの小さなプロジェクトに NHibernate を使用しました。さて、より大きなプロジェクトを開始する前に、データアクセスの設計方法とORMレイヤーを使用するかどうかの議論が始まりました。私はまだ見習いであり、まだエンタープライズプログラミングの初心者であると考えているため、データベースにオブジェクトリレーショナルマッパーを使用すると開発が非常に容易になるという意見をプッシュしようとはしませんでした。開発チームの他のコーダーは私よりもはるかに経験が豊富なので、彼らが言うことをやるだけだと思います。 :-)
ただし、NHibernateまたは同様のプロジェクトを使用しない主な理由の2つを完全には理解していません。
- SQLクエリを使用して独自のデータアクセスオブジェクトを作成し、それらのクエリをMicrosoft SQL Server Management Studioからコピーするだけです。
- 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'sPatterns of Enterprise Application Architectureには、これに対するさまざまなアプローチをカタログ化するかなり良い仕事をするデータアクセスパターンに関するセクションがあります。 ORMが適用されない状況で私が見たいくつかの例は次のとおりです。
ストアドプロシージャの実質的なレガシーコードベースを持つアプリケーションでは、機能指向（機能言語と混同しない）データアクセスレイヤーを使用して、既存のsprocをラップすることができます。これにより、既存の（したがって、テストおよびデバッグされた）データアクセスレイヤーとデータベース設計が再利用されます。これは、多くの場合、開発とテストにかなりの労力を費やします。多くの場合、JavaレガシーPL/SQLコードベースの周りのレイヤーをラップするか、Webインターフェースを使用してリッチクライアントVB、PowerbuilderまたはDelphiアプリを再ターゲットします。
バリエーションとは、必ずしもO-Rマッピングに適さないデータモデルを継承することです。 （たとえば）外部インターフェイスからデータを入力または抽出するインターフェイスを作成している場合は、データベースを直接操作した方がよい場合があります。
特に2フェーズコミットで複雑な分散トランザクションを使用している場合は、システム間データの整合性が重要な金融アプリケーションまたはその他のタイプのシステム。 ORMがサポートできるよりも優れたトランザクションのマイクロ管理が必要になる場合があります。
データベースアクセスを本当に調整したい高性能アプリケーション。この場合、より低いレベルで作業することが望ましい場合があります。
ADO.Netのような既存のデータアクセスメカニズムを「十分に」使用し、プラットフォームでうまくプレイしている状況は、ORMがもたらすよりも大きなメリットがあります。
データは単なるデータである場合があります。たとえば、アプリケーションが「オブジェクト」ではなく「トランザクション」で動作しており、これがドメインの適切なビューである場合があります。この例としては、構成可能な分析フィールドを持つトランザクションがある財務パッケージがあります。アプリケーション自体はオブジェクト指向プラットフォーム上で構築できますが、単一のビジネスドメインモデルに関連付けられておらず、GLコード、アカウント、ドキュメントタイプ、この場合、アプリケーションはビジネスドメインモデル自体を認識しておらず、オブジェクトモデル（元帳構造自体を超えて）はアプリケーションに関連していません。
まず最初に-ORMを使用しても、コードのテストが容易にならないだけでなく、継続的インテグレーションの場面で必ずしも利点が得られません。
私の経験では、ORMを使用すると開発速度が向上しますが、対処する必要がある最大の問題は次のとおりです。
- コードをテストする
- コードの維持
これらのソリューションは次のとおりです。
- コードをテスト可能にします（ [〜＃〜] solid [〜＃〜] 原則を使用）
- 可能な限り多くのコードの自動テストを作成する
- 自動テストをできるだけ頻繁に実行する
あなたの質問に来ると、あなたがリストする2つの異議は、何よりも無知のようです。
SELECTクエリを手で書くことができない（これが、コピーと貼り付けが必要な理由だと思われます）ことは、何らかのSQLトレーニングが緊急に必要であることを示しているようです。
ORMを使用しない理由は2つあります。
- 会社のポリシーで固く禁じられています（この場合、私はどこか別の場所で働きます）
- プロジェクトはextremelyデータ集約型であり、ベンダー固有のソリューション（BulkInsertなど）を使用する方が理にかなっています。
ORM（特にNHibernate）に関する通常の拒否は次のとおりです。
速度
ORMの使用が、手動でコーディングされたデータアクセスよりも遅くなる理由はありません。実際、キャッシュと最適化が組み込まれているため、より高速になります。優れたORMは、スキーマを最適化できる反復可能なクエリのセットを生成します。また、優れたORMを使用すると、さまざまなフェッチ戦略を使用して関連データを効率的に取得できます。
複雑
複雑さに関しては、ORMを使用するとコードが少なくなり、一般に複雑さが少なくなります。手書き（またはコード生成）データアクセスを使用する多くの人は、「低レベル」データアクセスライブラリ（ADO.Netのヘルパーメソッドの作成など）で独自のフレームワークを作成していることに気付きます。これらはより複雑になりますが、さらに悪いことに、十分に文書化されていないか、十分にテストされていません。
NHibernateを特に見ている場合、Fluent NHibernateやLinq To NHibernateなどのツールも学習曲線を柔らかくします。
ORMの議論全体について私に言えることは、ORMを使用するのは難しすぎる/遅い/何でも同じだと主張する同じ人々は、Linq To SqlまたはTyped Datasetsを使用することに満足している同じ人々であるということです。 Linq To Sqlは正しい方向への大きな一歩ですが、いくつかのオープンソースORMが存在する場所にはまだ数年遅れています。ただし、型付きデータセットとLinq To Sqlの両方のフレームワークは依然として非常に複雑であり、それらを使用して（テーブル=クラス）+（基本CRUD）の範囲外に移動するのは非常に困難です。
私のアドバイスは、1日の終わりにORMを取得できない場合、データアクセスが残りのコードから分離されていることを確認し、Gang Of Fourのコーディングのアドバイスに従うことです。インターフェース。また、依存関係注入フレームワークを取得して配線を行います。
（暴言はどうですか？）
HibernateのようなORMツールが神の送信である一般的な問題は広範囲に存在し、それが障害となる場所もいくつかあります。私はあなたのプロジェクトについて、それがどれであるかを知るほど十分に知りません。
Hibernateの長所の1つは、3回だけ言うことができることです。すべてのプロパティは、クラス、.hbm.xmlファイル、およびデータベースで言及されます。 SQLクエリでは、プロパティはクラス、データベース、選択ステートメント、挿入ステートメント、更新ステートメント、削除ステートメント、およびSQLクエリをサポートするすべてのマーシャリングおよびアンマーシャリングコードにあります！これは手間がかかります。一方、あなたはそれがどのように機能するか知っています。デバッグできます。サードパーティのツールの腸に埋もれているのではなく、あなた自身の永続化レイヤーにあります。
Hibernateは、SpolskyのLeaky Abstractionsの法則のポスター子になる可能性があります。打ちのめされた道から少し離れて、ツールの深い内部動作を知る必要があります。数分でSQLを修正できたと知っていると、非常に迷惑になりますが、代わりに適切なSQLを生成するためにDangツールを操作しようとして何時間も費やしています。デバッグは時々悪夢ですが、そこに行ったことがない人を納得させるのは難しいです。
編集：NHibernateを好転させるつもりがなく、SQLクエリを制御したい場合は、iBatis.NETを調べてください。
編集2：しかし、大きな赤い旗は次のとおりです。「ユニットテストや継続的インテグレーションなど、Stack Overflowではかなり普通と思われるグッドプラクティスは、現在のところ存在していません。」では、これらの「経験豊富な」開発者は、開発において何を経験していますか？彼らの仕事の安全は？あなたはその分野に特に興味のない人の中にいるかもしれないので、彼らにあなたの興味を殺させないでください。バランスを取る必要があります。戦います。
ORMを使用しないことが非常に成功した1つのプロジェクトに取り組みました。それはプロジェクトでした
- 最初から水平にスケールする必要がありました
- 迅速に開発されなければならなかった
- 比較的単純なドメインモデルがあった
NHibernateを水平に分割された構造で動作させるのにかかった時間は、分割スキームを認識していた超シンプルなデータマッパーを開発するのにかかった時間よりもはるかに長いでしょう...
ですから、私がORMで取り組んだプロジェクトの90％で、非常に貴重な助けになりました。しかし、ORMを使用しないことが最適であると判断できる特定の状況がいくつかあります。
ORMは適切に統合されていれば開発期間を短縮できますが、ORMが実際に規定の要件と目標の達成を妨げる可能性のあるいくつかの問題があります。
性能要件が厳しいシステムを設計するとき、システムのパフォーマンスを向上させる方法を見つけることがしばしば課題になります。多くの場合、書き込みパフォーマンスプロファイルが重いソリューションになります（つまり、データの読み取りよりもデータの書き込みの方がはるかに多いことを意味します）。これらのケースでは、パフォーマンス目標（OLAPではなくOLTP）を達成するために、データベースプラットフォームが提供する機能を活用したいと思います。したがって、SQL Serverを使用していて、書き込むデータがたくさんあることがわかっている場合、一括挿入を使用しないのはなぜですか...すでに発見されているように、ほとんどのORMS（たとえ1つであっても、一括挿入などのプラットフォーム固有の利点を活用する機能はありません。
ORMテクニックと非ORMテクニックをブレンドできることを知っておく必要があります。 ORMが要件をサポートできないEdgeのケースがいくつかあり、それらのケースでそれらを回避する必要があることがわかりました。
自明でないデータベースベースのエンタープライズアプリケーションの場合、ORMを使用しない正当な理由はありません。
脇の機能：
- ORMを使用しないことで、大規模なコミュニティや重要なリソースを持つ企業によって既に繰り返し解決されている問題を解決できます。
- ORMを使用することにより、データアクセスレイヤーの中核部分は、そのコミュニティまたは企業のデバッグ作業の恩恵を受けます。
引数にいくつかの観点を置くために、ADO.NETを使用することと、コードを記述して表形式のデータストリームを解析することの利点を考慮してください。
ORMを使用する方法の無知は、ORMに対する開発者の軽daを正当化するものです。たとえば、熱心な読み込み（あなたが言及していないことに気づいたこと）。顧客とそのすべての注文を取得し、それらすべての注文詳細項目を取得するとします。遅延読み込みのみに依存している場合、「ORMは遅い」という意見でORMの経験から離れます。熱心なロードの使用方法を学ぶと、同僚が実装するのに半日かかるコードを5行のコードで2分で実行できます。データベースへの1つのクエリとオブジェクトの階層への結果のバインドです。別の例としては、ページングを実装するためのSQLクエリを手動で作成する手間がかかります。
ORMを使用する場合の例外は、そのアプリケーションが、特殊なビジネスロジックの抽象化を適用するように設計され、複数のプロジェクトで再利用されるように設計されたORMフレームワークである場合です。ただし、その場合でも、これらの抽象化を使用して既存のORMを強化することで、より迅速に導入できます。
上級チームのメンバーの経験が、コンピューターサイエンスの進化とは逆の方向にあなたを引きずり込まないようにしてください。私は23年間専門的に開発を続けてきましたが、その定数の1つは、古い学校による新しいものに対する軽daです。 ORMはSQLに対するものであり、C言語はアセンブリに対するものであり、C++およびC＃と同等のものが登場することは間違いありません。新しい学校のコードの1行は、古い学校の20行に相当します。
50000000レコードを更新する必要がある場合。フラグなどを設定します。
ORM withoutを使用してこれを実行してみてください。ストアドプロシージャまたはネイティブSQLコマンドを呼び出します。
更新1：一部のフィールドのみで1つのレコードを取得してみてください。 （非常に「広い」テーブルがある場合）。またはスカラー結果。 ORMもこれを嫌います。
PDATE 2：EF 5.0ベータ版はバッチ更新を約束しているようですが、これは非常にホットなニュースです（2012年1月）
大きなシステムで作業するときは、ORMの代わりにCodeSmithのようなコードジェネレーターツールを使用できると思います...最近見つけました： Cooperator Framework C＃のビジネスエンティティ、マッパー、ゲートウェイ、lazyloadなどすべて...チェックしてください...アルゼンチンのチームによって作成されました...
データアクセス層全体のコーディングとORMの使用の中間だと思います...
個人的に、私は（最近まで）ORMの使用に反対しており、すべてのSQLコマンドをカプセル化するデータアクセスレイヤーの作成に慣れていました。 ORMに対する主な異議は、私がORM実装が正しいSQLを正確に記述することを信頼していなかったことです。そして、私がかつて見たORM（ほとんどPHPライブラリ））から判断すると、私は完全に正しいと思います。
今、私のWeb開発のほとんどはDjangoを使用しており、含まれているORMが非常に便利であることがわかりました。データモデルは最初にその用語で表現され、後にSQLでのみ表現されるため、ニーズに完全に対応しています。成長するのはそれほど難しくなく、手書きのSQLで補う必要があると確信しています。しかし、CRUDアクセスには十分以上です。
NHibernateについては知りません。しかし、私はそれがあなたが必要とするものの大部分にとって「十分」でもあると思います。しかし、他のコーダーがそれを信頼しない場合、すべてのデータ関連のバグの主な疑いがあるため、検証がより面倒になります。
職場に徐々に導入して、最初に単純なデータアクセスのような小さな「明らかな」アプリケーションに焦点を当てることができます。しばらくすると、プロトタイプで使用される可能性があり、置き換えられない可能性があります...
OLAPデータベース（たとえば、レポート/分析に使用される静的な読み取り専用データなど）である場合、ORMフレームワークの実装は適切ではありません。代わりに、データベースのネイティブデータアクセス機能を使用しますORMは、トランザクション（OLTP）システムにより適しています。
ORMを使用しない理由はたくさんあると思います。何よりもまず、私は.NET開発者であり、すばらしい.NETフレームワークが既に提供してくれたものに固執したいです。それは私がおそらく必要とするすべてを行います。これを行うことで、より標準的なアプローチを維持できるため、同じプロジェクトで作業している他の開発者が、そこにあるものを拾って実行できる可能性がはるかに高くなります。マイクロソフトが既に提供しているデータアクセス機能は非常に豊富であり、それらを破棄する理由はありません。
私は10年間プロの開発者であり、非常に成功した複数の100万ドル以上のプロジェクトを率いてきました。また、データベースに切り替える必要のあるアプリケーションを書いたことは一度もありません。なぜクライアントにこれをしてもらいたいのでしょうか？慎重に計画し、必要なものに合った適切なデータベースを選択し、それに従ってください。個人的にSQL Serverは、私が今まで必要としていたことを何でも行うことができました。それは簡単で、うまく機能します。最大10GBのデータをサポートする無料版もあります。ああ、それは.NETで素晴らしい動作をします。
最近、ORMをデータレイヤーとして使用するいくつかのプロジェクトで作業を開始する必要がありました。それは悪いことだと思うし、何も理由なく使用する方法を学ばなければならなかった。顧客がデータベースを変更する必要があるめったにない状況では、ORMプロバイダーにだまされていたよりも短い時間でデータレイヤー全体を簡単に作り直すことができました。
正直なところ、ORMの実際の用途は1つあると思います。複数のデータベースで実行する機能が本当に必要なSAPのようなアプリケーションを構築する場合。それ以外の場合は、ソリューションプロバイダーとして、このアプリケーションがこのデータベースで実行されるように設計されていることをクライアントに伝えます。繰り返しますが、10年と数え切れないほどのアプリケーションを経て、これは決して問題になりませんでした。
それ以外の場合、ORMは開発者向けのものであり、開発者にとってはあまり重要ではなく、アプリで使用するサードパーティのツールが優れているほど、アプリは良くなると思います。私はこのようなことを非常に難しいオタクに任せますが、その間、開発者がすぐに生産性を上げることができるはるかに優れたソフトウェアを作成します。
Hibernateで私が経験したことは、そのセマンティクスが微妙であり、問題がある場合、内部で何が間違っているのかを理解するのが少し難しいということです。私は友人からしばしばCriteriaで始まり、それからもう少し柔軟性とHQLが必要だと聞いたことがありますが、結局は生のSQLが必要であることに気付きました（たとえば、Hibernateには共用体AFAIKがありません）。
また、ORMを使用すると、既存のマッピング/モデルを使いすぎてしまう傾向があり、多くの属性が初期化されていないオブジェクトが存在することになります。そのため、クエリの後、トランザクション内でHibernateは追加のデータフェッチを行い、潜在的な速度低下につながります。また、悲しいことに、休止状態のモデルオブジェクトがビューアーキテクチャレイヤーにリークされることがあり、LazyInitializationExceptionsが表示されます。
ORMを使用するには、実際に理解する必要があります。残念ながら、簡単ではないのに簡単だという印象を受けます。
答えそのものではなく、最近聞いた引用を言い換えたいと思います。 「良いORMはイエティのようなものです。誰もが1つについて話しますが、誰もそれを見ません。」
ORMに手をかけるたびに、そのORMの問題/制限に苦労しています。最後に、はい、それは私が望むことをし、そのひどいドキュメントのどこかに書かれていましたが、私は自分が決して得られないもう1時間を失うことに気づきました。 nhibernateを使用し、その後postgresqlで流nなnhibernateを使用した人は、私がこれまでやってきたことを理解するでしょう。 「このコードは私の制御下にない」という絶え間ない気持ちは本当にひどいものです。
私は指を向けたり、悪いとは言いませんが、CRUDを1つの式で自動化するためだけに何を与えるのか考え始めました。最近では、ORMのより少ないものを使用する必要があると思います。おそらく、db操作を少なくとも可能にするソリューションを作成または見つける必要があります。しかし、それは私だけです。このORMアリーナではいくつかの点が間違っていると思いますが、それ以外のことを表現するには十分ではありません。
ORMの欠点のリストについては、この読書をお勧めします。
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
私自身にとって、私が書いたほとんどのアプリケーションにとってORMは非常に有用であることがわかりました！
/ Asger
実行時のパフォーマンスは、私が考えることができる唯一の本当の欠点ですが、ORMが開発/テスト/などを節約する時間の公平なトレードオフ以上のものだと思います。ほとんどの場合、データのボトルネックを特定し、オブジェクト構造をより効率的に変更できるはずです。
私は以前にHibernateを使用したことがありませんが、いくつかの「既製の」ORMソリューションで気づいたことの1つは、柔軟性の欠如です。これは、どちらを使用するか、そして何をする必要があるかに依存すると確信しています。
ORMには気になる2つの側面があります。第一に、それらは誰かによって書かれたコードであり、時にはクローズドソース、時にはオープンソースですが巨大なスコープです。次に、データをコピーします。
最初の問題は2つの問題を引き起こします。あなたは部外者のコードに依存しています。私たちは皆これを行いますが、そうする選択を軽視すべきではありません。そして、それがあなたが必要とすることをしないならどうしますか？これをいつ発見しますか？ ORMが描くボックスの内側に住んでいます。
2番目の問題は、2フェーズコミットの1つです。リレーショナルデータベースはオブジェクトモデルにコピーされています。オブジェクトモデルを変更すると、データベースを更新することになります。これは2フェーズコミットであり、デバッグするのが最も簡単なものではありません。
ORMを使用することはまだ良い考えだと思います。特にあなたが与える状況を考慮してください。あなたの投稿では、dbアクセス戦略に関してはあなたがより経験豊富であるように聞こえますが、私はORMを使用して立ち上げます。
クエリのコピーと貼り付けとテキストのハードコーディングは柔軟性を持たないため、＃1には引数がありません。＃2の場合、ほとんどのormは元の例外をラップし、生成されたクエリのトレースなどを許可します。
検証に関しては、ORMを使用すると、通常、組み込みの検証に加えて、検証戦略の開発がはるかに簡単になります。
独自のフレームワークを書くのは面倒であり、多くの場合見逃されます。
編集：私はもう一つのポイントを作りたかった。会社がORM戦略を採用すると、その価値がさらに高まります。使用および実装のガイドラインと実践を開発し、誰もが選択したフレームワークの知識をさらに強化し、提起した問題の1つを軽減します。また、状況が発生したときに何が機能し、何が機能しないかを学習し、最終的に多くの時間と労力を節約します。
すべてのORMには、たとえ「良いもの」であっても、アプリケーションレイヤーとデータストア間でデータをやり取りするためにソフトウェアが使用する、基礎となるメカニズムに関連する一定数の前提があります。
適度に洗練されたアプリケーションの場合、これらの仮定に対処するには、データのクエリや新しいエンティティの手動インスタンス化などの単純なソリューションを書くよりも時間がかかることがわかりました。
特に、コードをダウンロードしたときにORMから提供された便利な例の範囲外にある複数列のキーまたはその他の中程度に複雑な関係を使用するとすぐに問題が発生する可能性があります。
特定の種類のアプリケーション、特に非常に多数のデータベーステーブル、または動的に生成されたデータベーステーブルを持つアプリケーションでは、ORMの自動マジックプロセスが役立つことがあります。
それ以外の場合、ORMで地獄に。私は今それらを基本的に流行であると考えています。