私はJavaのバックグラウンドを持っています。
しかし、オブジェクトを永続化するためのベストプラクティスと考えられるものについて、クロスプラットフォームの観点が欲しいです。
私の見方では、3 つのキャンプがあります。
- ORM キャンプ
- JDBC/DAO、iBatis などの直接クエリ キャンプ
- リンクキャンプ
人々はまだクエリをハンドコーディングしていますか (ORM をバイパスします)? JPA、Django、Rails を介して利用可能なオプションを考慮してください。
1553 次
5 に答える
6
永続性のベストプラクティスは1つではありません（ただし、ORMがベストプラクティスであると叫ぶ人の数は、そうでないと信じさせる可能性があります）。唯一のベストプラクティスは、チームとプロジェクトに最も適した方法を使用することです。
データアクセスにはADO.NETとストアドプロシージャを使用します（ただし、SPクラスラッパージェネレーター、IDataRecordからオブジェクトへのトランスレーター、一般的なパターンとエラー処理をカプセル化する高階プロシージャなど、非常に高速に作成できるヘルパーがいくつかあります） 。
これには多くの理由がありますが、ここでは説明しませんが、それらは私たちのチームにとって有効な決定であり、私たちのチームが同意していると言えば十分です。結局のところ、これが重要です。
于 2008-12-12T12:26:15.473 に答える
3
少なくとももう1つあります：システム普及率。
私の知る限り、あなたにとって何が最適かはあなたの状況に大きく依存します。非常に単純なシステムの場合、直接クエリを使用することは依然として良い考えであることがわかりました。また、Hibernateが複雑なレガシーデータベーススキーマでうまく機能しないことを確認したため、ORMを使用することが常に有効なオプションであるとは限りません。すべてのオブジェクトをRAMに収めるのに十分なメモリがある場合、システムの普及率は非常に高速であると考えられます。LINQについてはわかりませんが、その用途もあると思います。
したがって、よくあることですが、答えは次のとおりです。特定の状況に最も適したツールを使用できるように、仕事に適したさまざまなツールを知ってください。
于 2008-12-12T12:10:42.417 に答える
3
現在、.net の永続オブジェクトについて調べています。そのため、ベスト プラクティスを提供することはできませんが、私の洞察が何らかのメリットをもたらす可能性があります。数か月前までは、ASP.classic 時代の悪い癖であるハンドコード クエリを常に使用していました。
Linq2SQL - 非常に軽量で, 使いこなすのが簡単. 厳密に型指定されたクエリの可能性と、SQL が一度に実行されないという事実が気に入っています。代わりに、クエリの準備ができた (すべてのフィルタが適用された) ときに実行されるため、データ アクセスをデータのフィルタリングから分離できます。また、Linq2SQL では、動的に生成されるデータ オブジェクトとは別のドメイン オブジェクトを使用できます。大規模なプロジェクトで Linq2SQL を試したことはありませんが、これまでのところ有望なようです。残念ながらMS SQLしかサポートしていません。
Entity Framework - 少しいじってみましたが、気に入りませんでした。私のためにすべてをやりたいようで、ストアドプロシージャではうまく機能しません。EF は、厳密に型指定されたクエリを再び許可する Linq2Entities をサポートします。MS SQL に限定されていると思いますが、間違っている可能性があります。
SubSonic 3.0 (アルファ) - これは、Linq をサポートする SubSonic の新しいバージョンです。SubSonic の優れた点は、簡単に変更できるテンプレート ファイル (C# で記述された T4 テンプレート) に基づいていることです。したがって、自動生成されたコードの外観を変更したい場合は、変更するだけです:)。まだプレビューを試しただけですが、今日はアルファ版を見ていきます。こちらをご覧くださいSubSonic 3 Alpha . MS SQL をサポートしていますが、Oracle、MySql などもすぐにサポートする予定です。
これまでの私の結論は、SubSonic の準備が整うまでは Linq2SQL を使用し、SubSonic テンプレートではより多くのカスタマイズが可能であるため、Linq2SQL に切り替えることです。
于 2008-12-12T11:33:34.310 に答える
2
私は自分で SQL を書くことを好みますが、そうするときはすべてのリファクタリング手法やその他の "良いこと" を適用します。
私は、データ アクセス レイヤー、ORM コード ジェネレーター、永続化レイヤー、UnitOfWork トランザクション管理、および大量の SQL を作成しました。非常に高性能なデータ フィード (4 万ファイル、1 日あたり合計 4 千万トランザクション、それぞれがリアルタイムで 2 分以内に読み込まれる) を含む、あらゆる形状とサイズのシステムでそれを行ってきました。
最も重要な基準は運命であり、それを制御します。ORM ツールが仕事を遂行する上での障害になったり、正しく行われていないことの言い訳になったりしないようにしてください。最終的に、すべての優れた SQL は手書きで手作業で調整されたものですが、適切なツールを使用すると、優れた最初のドラフトをすばやく作成できます。
この問題は、UI 設計と同じように扱います。私はすべての UI をコードで直接記述しますが、ビジュアル デザイナーを使用して、頭に浮かんだいくつかの重要な要素のプロトタイプを作成し、生成されたコードを分解して、独自のコードを開始します。
そのため、適切な例を得る方法として、ORM ツールをその表現のいずれかで使用してください。発生する多くの問題 (鍵の生成、関連付け、ナビゲーションなど) を ORM ツールがどのように解決するかを見てください。その出力を分解し、自分のものにしてから、それを再利用します。
于 2008-12-16T00:40:43.427 に答える
2
ベスト プラクティスは、状況によって異なります。
ある種の意味のある構造 (フィールドごとに 1 列、エンティティごとに 1 行など) を持つテーブル構造のデータベース オブジェクトが必要な場合は、オブジェクトとデータベースの間に何らかの変換レイヤーが必要です。これらは 2 つの陣営に分類されます。
データベースにロジックがなく (ストレージのみ)、テーブルがオブジェクトに適切にマップされている場合、ORM ソリューションは迅速で信頼性の高い持続性システムを提供できます。Toplink や Hibernate などの Java システムは、このための成熟したテクノロジです。
永続性に関連するデータベース ロジックがある場合、またはデータベース スキーマがオブジェクト モデルから大幅に逸脱している場合、データ アクセス オブジェクトでラップされたストアド プロシージャ (必要に応じて追加のパターンを使用) は、ORM よりも少し複雑ですが、より柔軟です。
構造化ストレージが必要ない場合 (既存のデータに構造化ストレージを導入するのは面白くないので、そうしないことを本当に確認する必要があります)、多くの複雑さを回避して、シリアル化されたオブジェクト グラフをデータベースに直接保存できます。
于 2008-12-12T14:21:12.683 に答える