これらのソフトウェア アーキテクチャのそれぞれが、どの分野で優れているか、または失敗するか?
どちらかを選択するよう促す重要な要件はどれですか?
優れたオブジェクト指向コードと優れたデータベース開発を行える開発者がいると仮定してください。
また、聖戦は避けてください :) 3 つのテクノロジにはすべて長所と短所があります。
4801 次
6 に答える
13
これらのツールはそれぞれ、動作をオーバーライドするためのさまざまなポイントとともに、さまざまな抽象化レイヤーを提供します。これらはアーキテクチャの選択であり、すべてのアーキテクチャの選択は、テクノロジー、コントロール、および組織の間のトレードオフ、アプリケーション自体とそれが展開される環境の両方に依存します。
DBA が「ねぐらを支配する」文化を扱っている場合は、ストアド プロシージャ ベースのアーキテクチャを展開する方が簡単です。一方、ストアド プロシージャの管理とバージョン管理は非常に困難な場合があります。
コード ジェネレーターは、実行時ではなくコンパイル時にエラーをキャッチできるため、静的に型付けされた言語を使用する場合に役立ちます。
ORM は、インストールごとに異なる RDBMS とスキーマを処理する必要がある統合ツールに最適です。1 つのマップを変更すると、アプリケーションは Oracle 上の PeopleSoft との連携から、SQL Server 上の Microsoft Dynamics との連携に移行します。
コード ジェネレーターの制限を回避するためにストアド プロシージャを微調整できるため、Generated Code を使用してストアド プロシージャとやり取りするアプリケーションを見てきました。
最終的に唯一の正解は、解決しようとしている問題と、ソリューションを実行する必要がある環境によって異なります。それ以外は、'potato' の正しい発音について議論しています。
于 2008-09-16T20:42:10.363 に答える
10
私は2セントを追加します：
ストアド プロシージャ
- 簡単に最適化できる
- 基本的なビジネス ルールを抽象化し、データの整合性を強化する
- 優れたセキュリティ モデルを提供する (正面向きの db ユーザーに読み取りまたは書き込みのアクセス許可を付与する必要はありません)
- 多くのアプリケーションが同じデータにアクセスしている場合に最適
ORM
- ドメインのみに集中し、より「純粋な」オブジェクト指向のアプローチで開発を行うことができます
- アプリケーションが相互データベース互換性を備えている必要がある場合に輝きます
- アプリケーションが主にデータではなく動作によって駆動される場合に輝く
コードジェネレーター
- ORM と同様のメリットがあり、メンテナンス コストは高くなりますが、カスタマイズ性は向上します。
- 一般に、ORM はコンパイル時エラーと実行時エラーを交換する傾向があるという点で、ORM よりも優れています。これは一般的に回避する必要があります。
于 2008-09-16T20:44:42.773 に答える
5
すべてに長所と短所があり、多くはアーキテクチャに依存することに同意します。そうは言っても、私は理にかなっている場合はORMを使用しようとしています。機能の多くは既に存在しており、通常は SQL インジェクションの防止に役立ちます (さらに、車輪の再発明を回避するのに役立ちます)。
詳細については、このトピックに関する他の 2 つの投稿 (動的 SQL とストアド プロシージャと ORM) を参照してください。
動的 SQL とストアド プロシージャ
アドホック クエリとストアド プロシージャのどちらが優れているか?
ORM とストアド プロシージャ
NHibernate によって生成されるパラメータ化された SQL は、ストアド プロシージャと同じくらい高速なのはなぜですか?
于 2008-09-16T20:14:39.557 に答える
3
ORM とコード ジェネレーターはフィールドの片側にあり、ストアド プロシージャは別の側にあります。通常、グリーンフィールド プロジェクトでは ORM とコード ジェネレーターを使用する方が簡単です。これは、作成するドメイン モデルに合わせてデータベース スキーマを調整できるためです。ソフトウェアが「データファースト」の考え方で書かれると、それをドメインモデルでラップするのが難しいため、レガシープロジェクトでそれらを使用することははるかに困難です.
そうは言っても、3 つのアプローチすべてに価値があります。ストアド プロシージャは最適化が容易ですが、アプリケーション自体で繰り返される可能性のあるビジネス ロジックを格納したくなる場合があります。スキーマが ORM の概念と一致する場合、ORM は適切に機能しますが、そうでない場合はカスタマイズが困難になる可能性があります。コード ジェネレーターは、ORM の利点の一部を提供しますが、生成されたコードのカスタマイズを可能にするため、良い中間点になる可能性があります。再生成するたびに変更する必要があります。
唯一の正解はありませんが、私はオブジェクト ファーストの考え方で考える方が理にかなっていると信じているため、ORM 側に傾倒しています。
于 2008-09-16T20:24:38.097 に答える
2
独自のカテゴリに値する重要なオプション、つまりiBatisなどのハイブリッド データ マッピング フレームワークを忘れていました。
私は iBatis に満足しています。オブジェクト指向コードを本質的にオブジェクト指向のままにし、データベースを本質的にリレーショナルのままにし、3 番目の抽象化 (オブジェクトと関係の間のマッピング層) を追加することでインピーダンスの不一致を解決するからです。一方のパラダイムを他方のパラダイムに強制的に適合させようとするのではなく、2 つをマッピングします。
于 2008-09-19T20:38:53.720 に答える
2
ストアド プロシージャ
- 長所:データ アクセス コードをカプセル化し、アプリケーションに依存しない
- 短所: RDBMS 固有であり、開発時間が長くなる可能性があります
ORM
少なくとも一部の ORM では、ストアド プロシージャへのマッピングが許可されています
- 長所:データ アクセス コードを抽象化し、エンティティ オブジェクトをドメイン固有の方法で記述できるようにする
- 短所:パフォーマンスのオーバーヘッドの可能性とマッピング機能の制限
コード生成
- 長所:ストアド プロシージャ ベースのコード、ORM、または両方の組み合わせを生成するために使用できます。
- 短所:生成されたコードを理解するだけでなく、コード ジェネレーター レイヤーを維持する必要がある場合があります。
于 2008-09-16T20:30:06.477 に答える