7

これは問題を単純化したものです (さまざまな方法があります) が、データベースと対話する必要があるアプリケーションの中で、私は通常、次の 2 つのパターンのいずれかを見てきました。

  1. オブジェクト リレーショナル マッピング (ORM)。(通常) データベース内の各テーブルには、テーブル内の列に一致するパブリック プロパティを持つ、対応する「行ラッパー」クラスがあります。これらのクラスは関連情報を自動的に取得する場合もあるため、代わりに外部キー列を公開して関連データとして表示することができます (単なる PK 値ではなく)。
  2. DataTables (および/または DataSets)。データはサーバーから DataTable として取得され、その形式で (UI 内でも) 処理されます。

2 つのアプローチの主な違いの 1 つは、ORM ではコード内で次のように厳密に型指定されたフィールドを参照できることです。

Person bob = new Person();
bob.FirstName = "Bob";
collectionPeople.Add(bob);

一方、DataTable アプローチでは、コードは次のようになります。

DataRow newrow = datatablePeople.NewRow();
newrow["FirstName"] = "Bob";
datatablePeople.Rows.Add(newrow);

この場合、ORM アプローチはコンパイル時チェックの恩恵を受けますが、DataTable アプローチは恩恵を受けません。一方、DataTable (および DataSet) は、リレーショナル データを直接表現する優れた機能を備えた既に作成されたデータ構造であるため、これらを使用するコードは通常、より迅速に実装できます。さらに、DataTable を使用するコードは、他のユーザーが簡単に理解したり変更したりできます。自社製 (および多くの場合 COTS) の ORM システムは、多くの場合、外部キーなどを設定するために「内部で」余分なデータベース アクセスを行います。

では、一般的にどちらのアプローチを支持しますか?またその理由は?

4

8 に答える 8

8

私は年を取り、疲れていて、SubsonicやLinqのようなファッションに懐疑的であるため、DataTablesの方法を好みます。

それを超えて、ORMで作業しているときは、通常、SQLで行うことを最小限に抑えています。SQLに多くのロジックを配置したり、データベースへの1回のトリップで複数のことを実行するために複数のSQLステートメントをバッチ処理したりすることはありません。したがって、データベースに頻繁にアクセスする傾向があり、これはパフォーマンスに大きな打撃を与えます。

データセットを使用して、次のようなことができます。

col1、col2 ...をtable1から
選択します。col1、col2 ...をtable2から
選択します。col1、col2...をtable3から選択 します。

次に、データベースに1回アクセスして、Tables [0]、Tables [1]、Tables [2]を使用して、3つのデータセットすべてを取得します。パフォーマンスに大きな違いがあります。

いつの日か、データベースとの対話が非常に速くなり、SQLをバッチ処理しても意味がなくなるかもしれませんが、その日はまだここにありません。それが来たら、私はORMに切り替えますが、それまでは、パフォーマンスと引き換えにコードを少し醜くしていきたいと思っています。ユーザーが遅いアプリを使うのは楽しいことではありません。

最後に、SQLが好きです。私はSQLが得意です。本当に良い。必要なSQLを出力するようにLinqを強制する方法を考え出すことに時間を費やしたくありません。パフォーマンスが低下します。

于 2008-11-07T11:32:54.957 に答える
8

Datatable は、データを操作する上で、概念的にはより単純です。また、ORM で見られるような不自然なイディオムもありません。(レコードを更新する前に、ローカル メモリにクエリを実行します。結合はポインターです。キー値自体はポインターであるため、レコードを追加するには、親レコードをロードする必要があります)

ORMの大きな利点は...

1）それはあなたのためにSQLを書くので、基本的なcrudをするために実際にSQLを書く必要はありません. もちろん、より複雑なステートメントを書くには、それほど強力ではないサブ言語 (つまり、hql) で行う必要があります。

2) ORM のもう 1 つの大きな利点は、結果を返すときに、値をマップして型変換を処理するためのコードを大量に記述することなく、結果を値オブジェクトにマップすることです。

あなたが強力なSQLスキルを持っているが、アドバンテージ2をカバーしたい場合、私はibatisを選びます

于 2008-11-07T13:30:32.257 に答える
4

強く型付けされたデータセットを使用して、前述の両方のアプローチを組み合わせることができます。

[新しいアイテムの追加]ダイアログの[データセットテンプレート]を使用してVisualStudioプロジェクトに追加し、ビジュアルデータセットデザイナーを使用することができます（XSDファイルをバックグラウンドで編集します）。

主題に関する別の記事があります。

于 2008-11-07T11:47:56.923 に答える
4

.Net では、強く型付けされたデータセットには、ORM に帰する利点があります。IDE と Intellisense での強い型付けの価値です。

Visual Studio で作成された TableAdapter は、すべての CRUD SQL を書き込みます。ビジネス ロジックを SQL ではなく C# (または他の言語) に配置します。

データセットによって提供される切断されたデータ モデルは、実際には、典型的な手作業でコーディングされた SQL よりも効率的であることが証明されていると思います。これにより、関連するすべてのテーブル データを 1 回のクエリで取得する、おしゃべりではない DB インタラクションが発生します。また、楽観的ロック (DBConcurrency 例外を提供する) を非常に適切にサポートしています。データセットは、データへの挿入、変更、および削除も追跡するため、その必要はありません。

厳密に型指定されたデータセットは、関連するテーブル データへの簡単なナビゲーションも提供します。

DataSets に関する参考資料は次のとおりです。

David Sceppa による Microsoft® ADO.NET 2.0 コア リファレンスのプログラミング

発行元: Microsoft Press Pub 日付: 2006 年 5 月 17 日 印刷 ISBN-10: 0-7356-2206-X 印刷 ISBN-13: 978-0-7356-2206-7 ページ: 800

+トム

于 2008-11-30T00:21:14.863 に答える
3

データ オブジェクトと DataTables の利点を比較します (優れた ORM ライブラリは必要ありませんが、実際には必要ありません)。

  • コンセプト的にクリーン。オブジェクト指向の概念をデータに適用する必要があります。「これは人です」と「私が望む人はこのテーブルのどこかにいます」よりも理解しやすいです。
  • 関心の分離を強制します。UI コンテキスト データを DataTable に追加するのは魅力的です。ある UI では、同じレコードに主要な住所を持つ Person を取得し、別の UI では、同じレコードに信用情報を持つ Person を取得します。モデルを扱うときは、そのモデルをどこで使用しても一貫性が保たれるようにしたいと考えています。

  • データを 1 回だけ変換します。私が見た DataTable 処理アプリでは、これがあちこちに散らばっています。

    if(row["col"] == DBNull.Value || string.IsNullOrEmpty(row["col"] as string)) ...

    DataTable が使用されているすべての場所でチェックするのではなく、データ オブジェクトを作成するときにその条件を 1 回チェックしたいと思います。

  • 単体テストが容易になります。存在しないデータ オブジェクトのフィールドを参照すると、コンパイル エラーが発生します。存在しない DataTable のフィールドを参照すると、実行時エラーが発生します。

私は、ORM があなたを怠け者にできると信じています。たとえば、これらのオブジェクトが常に一緒に使用される場合、オブジェクト内の個々のクエリから一連の関連データ オブジェクトを設定する理由はまったくありません。代わりに、必要なすべてのデータを取得してからデータ オブジェクト グラフを作成する、大規模で効率的なクエリを記述します。それでも、その制限を念頭に置いておけば、多くの作業を節約できます。

関連:エンタープライズ開発にデータセットを使用しないように同僚を説得する方法 (.NET 2.0+) .

于 2008-11-07T16:43:37.920 に答える
2

私は .NET の初期に DataSet を使用していましたが、その後、型指定された DataSet を使い始めました。時間が経つにつれて、DataSet によって残されたメモリ フットプリントが非常に高く、すべての単純なタスクにアンマネージ オブジェクトを使用する意味がないことがわかりました。
したがって、DTO/POCO がより良い選択であると結論付け、NHibernate と iBatis の使用を開始しました。
私の平均的な（または平均以下の）開発者は、それらが複雑で使いにくいと感じました（しゃれた意図はありません）。
そこで、複雑な ORM よりもはるかに使いやすい自家製のORM XmlDataMapperを作成しました。

XmlDataMapper を統合するには、4 つの小さな手順を実行するだけです

  1. テーブルの事業体/DTO を作成する
  2. テーブルと DTO の間のマッピング情報を含む XML ファイルを作成します。
  3. 構成で DTO および xml ファイルを指定します。
  4. DTOConverter.Convert(dataReader) などのメソッドを呼び出して、データベース レコードを DTO / ビジネス エンティティに変換するだけです。
于 2010-06-21T12:18:57.193 に答える
0

以前は、データリーダーを使用してGetString、GetIntなどを使用してオブジェクトにフィールドを読み取るだけでしたが、ゲートウェイを使用してクエリからデータテーブルを返す、はるかにOOでテスト可能なアプローチに移行しました。これは、に渡されます。テーブルをオブジェクトに解析するServiceクラス。

私はORMツールが本当に好きではありませんでした。それらは常に面倒で保守が困難でしたが、まだLINQで遊ぶ機会がなかったので、私の意見は変わるかもしれません。

于 2008-11-07T11:32:08.687 に答える
0

DataSets/DataTables よりも ORM を使用すると、開発するコードが少なくなり、コードをより適切にテストできることがわかりました。現在、LINQ-to-SQL を使用しており、ORM として部分クラスを介してデザイナーが生成したコードを薄いレイヤーでラップしています。基本的に、シン レイヤーを使用すると、役割ベースのアクセス許可をいくつか追加でき、インターフェイスをリファクタリングし、依存性注入を使用してデータ コンテキストを指定することで、コードのテスト容易性を高めることができます (そうすれば、他のテスト用にモックアップできます)。

私は両方を行いました-DS/DT、厳密に型指定されたDS/DTなどに独自のORMを作成し、LINQに切り替えましたが、元に戻りません。最終的には NHibernate や Entity Framework などに移行するかもしれませんが、今のところ、私の LINQ ソリューションは必要なものをほとんどすべて提供しており、以前のソリューションよりもはるかにシンプルです。

于 2008-11-07T12:15:52.687 に答える