orm - ORM とハンドコードされたデータアクセスレイヤー

Question

宗教戦争が始まるかもしれないので、この質問をするのは少し怖いので、私が探しているものを明確にしたいと思います. 私は、あなたがどちらかの方法でジャンプしたい、またはジャンプした理由と、私のリストに追加するアイテムを探しています. ビッグチケット、ビッグバンのアイテムを探しています。また、製品に固有のアイテム (実際に関連性がある場合)。この時点で、製品 A と製品 B ではなく、ORM とマニュアルを評価しようとしています。

ORM の利点

- 迅速なコーディングと低メンテナンス (一部/ほとんどのシナリオで)
 - 「無料」の追加機能 (開発者の労力なし)

ハンドコーディングの利点

- より効率的 (実行時、おそらく開発時ではない?)
 - 複雑さの少ないレイヤー
 - ほとんどの ORMS は、sprocs のみに制限されることに苦労しているようです

完全な開示のために、データベースに対して直接変更できないコードを「何か」が実行するという考えは本当に好きではありませんが、ORM の潜在的に膨大な開発時間の利点を見ることができます。

私が.Netの世界にいることもおそらく注目に値します

[編集] ( Using an ORM or plain SQL?の質問は、多くの質問に答え、パフォーマンスに関するポイントを補強しているようです)

だから、私の質問を少し変えるために

初期段階で ORM を使用してアプリを構築し、その後徐々にハンドコーディングされた DAL に置き換えた人はいますか? このアプローチの落とし穴は何でしたか?

[さらに編集 - 今すぐ問題の核心に迫る] データベースに対して任意の SQL を実行できる Web サイトを持つことは恐ろしいことです。すべてのアクセスが sprocs を介して行われる場合、私のデータベースは適切で安全で快適な分離状態に置かれます。排他的に sprocs を使用すると、すべてではないにしても多くの SQL インジェクション攻撃ベクトルが除去されます。それについて何かコメントはありますか？

score 16 · Accepted Answer

私たちは当初、JPA を使用してアプリケーションを作成しました。それが製品化された日以来、後悔しています。ORM によって行われるデータベース呼び出しの量は天文学的なものであったため、Spring の JDBC ヘルパークラスを利用した古き良き JDBC を使用して、アプリケーションを少しずつ書き直すプロセスを開始しました。ORM から始めることの落とし穴は、JPA の学習にかなりの時間を費やしたことです。その日の終わりには JDBC に置き換える必要があるため、Oracle RAC に他の 3 つのノードを追加することなく、アプリケーションをよりスケーラブルにすることができます。したがって、バランスを取れば、JDBC の制御と精度は、作成しなければならない追加のコード行に値するものでした。また、ほとんどの人は、SQL が生成可能で実行できるものではないことを理解していません。

score 7 · Accepted Answer

私はいくつかの大きなプロジェクトにSubsonicを使用しました。私は、あるORMを別のORMよりも使用することを推奨していませんが、ORMなしで別のデータベース関連プロジェクトを実行することはありません。データベース構造を変更するたびにdbアクセスレイヤー全体を再生成する機能、DBレイヤー全体に影響を与える機能を1か所に追加する機能。

重要なのは、データベースとの相互作用を理解する必要があるということです。そうしないと、（大幅に）パフォーマンスの低いコードを作成するリスクがあります。ORMツールを使用すると、データのオブジェクト指向の優れたビューが得られる場合がありますが、単純な処理を行うためにテーブル全体をクライアントにストリーミングしている場合があります。データベースはデータの関連付けとフィルタリングに優れているため、データベースにその役割があることを確認してください。皮肉なことに、Subsonicの結合の欠如（私が使用したバージョンでは）は、必要に応じてデータを結合するためのDBビューを作成することを余儀なくされたため、それを助けました。

私の友人は、社内のORMツールを開発した人と一緒に仕事をしました。これには、外部キーをウォークスルーすることで、データベースから必要になる可能性のあるすべてのものをローカルにキャッシュするという優れた機能がありました。欠点は、DBの1つの行から1つの列を読み取ると、11,000を超えるselectステートメントが生成されることでした。

score 6 · Accepted Answer

私は 8 年間、独自の ORM を書き、維持してきました。Java で始まり、C# に翻訳されました。それなしでデータベースに支えられたシステムを書くことは想像できません。これは NHibernate よりもはるかに単純であり、すべての機能を備えているわけではありませんが、XML 構成を DAO クラス定義のリフレクションに置き換えるため、リフレクションを広範囲に使用しますが、仕事は完了し、非常に高速です。

私はそれに非常に満足しており、他のアプローチは使用しません。

編集: SQL インジェクション攻撃について: この ORM を使用して開発した最近のシステムは広範囲に監査され、インジェクションはまったく許可されませんでした。理由は簡単です。オンザフライで SQL を生成し、常にパラメーターを使用し、文字列連結を使用しません。

score 5 · Accepted Answer

数週間前、私は新しいプロジェクトの開発を開始しました。使用できるツールを完全に制御できました。この問題を完全に排除したかったので、db40 から始めました。オブジェクトを直接保持したかっただけで、ADO.NET や OR/M は忘れてください。しかし、db40 には問題があったので、私はそれを放棄しなければなりません。

次に選んだのは ADO.NET で、高速で簡単だと思ったからです。しかし、私はあまりにも多くのコードを書かなければならず、あまりにも多くの "string sql" を使用しなければなりませんでした。つまり、それは王室の PITA であり、それを使用して 2 つのリポジトリをコーディングした後、手首を切断したいと思いました。

私の 3 番目の選択肢は NHibernate でした。以前、切断されたオブジェクトを使用する必要がある状況で NHibernate に問題がありました (今回も同様でした。そのため、到達するのに 3 回の試行が必要でした)。しかし、それは NHibernate 1.2 でした。今回は 2.0 バイナリを取得し、切断されたオブジェクトの更新に問題はありませんでした。また、コードの行数を大幅に減らす必要があり、リファクタリングが必要なときに非常にシンプルでした。これは、設計が急速に変化したため、おそらく最も重要なことでした。

私は今NHibernateで売られています。高度に最適化されているようにも見えます。正直なところ、私はそれに否定的なものを見つけることができません。また、ストアドプロシージャはありません。

私はそれが私の OR/M の選択であることを知っており、二度と直接 ADO.NET を書くことはありません。

score 3 · Accepted Answer

特に既存のスキーマがインストールされていない場合、ORM は最初のうちは「すばやくコーディングできる」だけだと私は主張します。システムからより多くのパフォーマンスを引き出す必要がある場合は、「すぐに破棄」できる ORM が必要になります。

私はそれらがワームの缶であることを発見しました。

score 3 · Accepted Answer

私はこれに数年間苦労してきました。いろいろ見てきた。そして、この 3 か月間で、「なぜ私はこれに時間を浪費しているのだろう」と気づきました。私は、ORM を解決済みの問題と見なしています。私よりも、ORM に完全に集中しているチームが ORM レイヤーを作成することを信頼したいと思います。精神的には、新しい挑戦の準備ができています。

私の選択はNHibernateです。私は今、これに本当に初心者です。しかし、Fluent NHibernate や Castle ACtiveRecord を使用する可能性も気に入っています。これがマインドシェアの場所のようです。

しかし、「すべてがsproc」の世界で私が何をするかはわかりません。

score 3 · Accepted Answer

赤豆を試しましたか？開発段階では流動的で使いやすく、本番モード (凍結) では高速です。 http://redbeanphp.com

score 1 · Accepted Answer

NHibとMyGenerationで作成されたWebアプリを継承しましたが、残念ながらsvnリポジトリを取得できず、初期テンプレート（arrggg）がありません。

Create / Update / Deleteバックエンドのもののためにnhibernateを維持しましたが、フロントエンド（読み取り専用）はやや無意識のうちに実装され、2本足の犬のように動作し、現在は昔ながらのADO.NETで書き直されています。 10倍速くなります。

これがNHibernateによるものだと言っているのではなく、開発者がネットワークに沿ってどれだけのがらくたを送っているのかわからないためであり、ツールを盲目的に使用することは彼らがそれについて考える必要がないことを意味すると仮定します。

読み取り専用クエリの目的で、多くの場合、手動で作成する方がはるかに効率的です。

DBに書き込む必要があるものについては、まともなORMに書き込むのが一般的に簡単で、それほど遅くはありません。

私の個人的な好みはSubSonicです。これは、中規模のプロジェクトで非常にうまく機能することがわかりました。ボトルネックが見つかった場合は、手作業で回避できます。

ツールは素晴らしいです、そして私にもっと週末を与えるものは二重に素晴らしいです、しかしあなたの耳の間にツールに代わるものはありません。

score 1 · Accepted Answer

ストアドプロシージャは、SQLインジェクションのリスクを排除しません。コードでクエリを連結する可能性が高い人は、ストアドプロシージャでも同様に連結する可能性があります。そして、良いORMはとにかく文字列連結を行わないので、問題はありません。

score 1 · Accepted Answer

Stored Proc の質問にコメントしてください。機能がどのように記述されても、DAL、ORM、ストアドプロシージャ、SQL が含まれます。ストアドプロシージャを使用する場合は、内部に SQL を記述します。有用な抽象化を組み込むのは比較的簡単です。DAL を使用する場合は SQL を記述しますが、実際には、インジェクションの危険性が高く、抽象化されていない SQL である可能性が高くなります。ORM を使用する場合、ツールは SQL を書き込みます (ただし、最終的にはユーザーが責任を負います - 注入可能性を含みます)。私見ですが、可動部分 (特に、あなたが知っていて理解している部分) が少ないほど良いのです。

score 1 · Accepted Answer

オブジェクトデータベースを使用する本番アプリの DAL を書き直さなければなりませんでした。オブジェクト DB と SQL データベースの両方をサポートしたかったのです。機能がすでに存在する場所に実装したくないいくつかの機能

クエリごとのオーバーライドによる透過的な遅延読み込み
エンティティ ID (等しいエンティティに対しては常に同じ参照を取得します)
バッチ処理の挿入/更新
バッチ処理の選択 (NHibernate の先物)
ID世代
クエリ API を sql に変換する (クエリ API のモジュール性により、基準は完璧でした)

それが、私が満足している ORM として NHibernate を選んだ理由です。そして、私はいくつかの素晴らしい機能を無料で手に入れました。

クラスの自動マッピング (全体のマッピングを生成するための合計 3 ページのコード)
LINQ サポート (自分で LINQ プロバイダーを実装しようとしたことがありますか?)
無料で広範なロギング
インメモリ sqlite による単体テストの簡素化
さまざまな db プロバイダーのサポート
スキーマ生成は非常に簡単です (異なるデータベースプロバイダーの生成スクリプトを維持する必要はありません)
楽観的並行性
N/Hibernate のドキュメントは、リレーショナル手法の優れた学習リソースです

NHibernate が生成しているものよりも優れたパフォーマンスの SQL を手動で記述する方法を想像することはできません。反対のいくつかの議論:

少数のプロパティのみが必要な場合にオブジェクト全体をロードします --> DTO への射影、または C# 3.0 では匿名型への射影が常に存在します (SetProjection() / Select())
結合の代わりに多くの選択 --> 必要に応じて熱心な読み込みを使用 (SetFetchMode() / Fetch())
微調整されたSQLは常に生成されたものよりもパフォーマンスが高い->アーキテクチャの最適化>>マイクロ最適化。ORMを使用すると、コードが少なくなり、ロジックの繰り返しが少なくなるため、アーキテクチャのリファクタリングがはるかに簡単になりました（1対多から多対のようなものを変更してみてください多くは手書きのダル）

score 0 · Accepted Answer

いい質問といい答え。私もこれらの問題に関与しました。手作業でコーディングされたDALよりもSubSonicのようなORMの方が好きです。

score 0 · Accepted Answer

.NetでDataSetを使用するだけで非常に成功しました。最初に.XSDを使用して入力を検証するSOAPエンドポイントがあります。次に、ルールエンジンを使用して検証を行うことができます。それで...

リクエストがデータの挿入である場合：

DataSetでGetXml（）を使用してXMLに変換します。
SQLServerでOPENXMLを使用するsprocにXMLを送信します。

リクエストがデータの選択である場合：

複数のSELECTステートメントを使用してデータを吐き出すsprocを記述します。
そのデータをDataSetにロードします（必要に応じて「ネストされた」関係を構築してください）。
DataSetでGetXml（）を使用して、SOAPで使用されるXMLに変換します。

私はこのプロセスを使用して、いくつかの実稼働環境で大成功を収めました。SQL Serverのみを使用することがわかっている場合は、高速で簡単です。

score 0 · Accepted Answer

私は個人的なプロジェクトのためにNHibernateでCastleProjectのActiveRecord実装を使用しました。プロジェクトが展開されることはありませんでした。これは、私が行ったORMの選択を処理できなかったことが一因です。

ORMを使用することにした理由は、コードを変更せずにSQLServerからMYSQLに切り替える機能が必要だったためです。実際のプロジェクトでは、SQLサーバーを使用するという決定はすでに行われており、データベースが変更されないことがわかっている場合は、従来の3層の方法でデータレイヤーを作成する方が簡単です。しかし、個人的なプロジェクトでは共有ホスティングを使用しており、MySQLはより安価なソリューションです。

Castleを選んだ理由は、とても使いやすかったからです。Visual Studio用のactivewriterプラグインを使用すると、デザイナー（linq to SQLデザイナーのようなもの）を使用してクラスとデータベースを生成でき、ORMがアプリケーションアーキテクチャをどのように決定するかという私のメンタルモデルにうまく適合しているようです。。

そのORMで私が抱えていた問題は、それを適切に最適化する方法に関する情報を見つけることができなかったということでした。データベースに対して非常に大きな呼び出しを行っていました。（ユーザーを取得するために生成されたSQLクエリは、ログに記録したときに1 MBのテキストでした。）

そのため、ORMを使用して、事前に多くの作業を節約しましたが、フレームワークが大量のSQLを生成する問題を修正しようとすると、壁にぶつかりました。（私はまだゆっくりと取り組んでいます）。

完璧なソリューションは見つかりませんでしたが、他の個人的なプロジェクトではORMを試してみました。それは私だけであり、プロジェクトの時間をデータレイヤーではなく楽しいコードに費やしたいからです。

ただし、仕事では、専門家になる前（おそらく、いくつかの個人的なプロジェクトを自分のベルトの下で行った後）に、ORMを使用することを提案するのは早すぎることはないでしょう。

score 0 · Accepted Answer

わかりました、これは .net アプリケーションではなく PHP アプリケーション用でしたが、同じ品質が重要だと思います。

私は数年前にデータベースベースの PHP イントラネットアプリを書き直しました。「成長したばかり」の多くの PHP アプリによくあることですが、ORM をまったく使用しておらず、多くの重複コードがあり、その多くは同様のクエリをさまざまな方法で組み立てていました。

いくつかの ORM フレームワークをざっと見てみましたが、どれも大きな問題を抱えていました。私たちの構造で機能させるには、それらをカスタマイズする必要がありました。欠けている大きなコンポーネントは、データベースのスケーラビリティでした。そこで、独自のハンドラーを作成しました。その後、継続して独自のオブジェクトベースのデータレイヤーを構築するのは簡単なことでした。また、必要な機能を実装する必要がありました。

振り返ってみると、これは私にとって非常に有益な演習でした。これは、ORM レイヤーがどのように機能し、どのように機能する必要があるかを理解したということです。また、データに関する知識が存在するアプリケーションに問題が持ち上がったため、多くのデータベースのスケーリングの傾向に逆らっていました。

score 0 · Accepted Answer

nHibernate のような優れた ORM を使用して、SPROC や手作りの SQL を放棄する必要はありません。

事後、ORM データアクセスメソッドを置き換えました。まったく難しいことではありません。両方の長所を備えています。

orm - ORM とハンドコードされたデータ アクセス レイヤー

16 に答える 16

Related

Reference

orm - ORM とハンドコードされたデータアクセスレイヤー