3

読み取りデータベースにクエリを実行し、DTO を設定するために、人々はどのツールを使用していますか?

現在、Sql2008 データベースに読み取りモデルがあり、WCF サービスを介してすべてのクエリを実行しています。Fluent NHibernate を使用して、自動マッピングを使用してデータ コントラクトを設定していますが、これはやり過ぎでしょうか?

私たちの要件は本当にこれです...

  1. Web サービスに SQL コードがありません
  2. Web サービスにマッピング コードはありません。理想的には、規則に従ってマッピングする必要があります。読み取りデータベース フィールドは、データ コントラクト プロパティと同じ名前を持ちます。手動でマッピング コードを記述して保守することは望ましくありません。
  3. Web サーバーのリソース使用量を最小限に抑えます。
4

3 に答える 3

3

私見オーバーキル。

JSON/ProtoBuf シリアライゼーションを備えたフラット ファイル システムのみを使用しています。Web サービスは非常にシンプルで、スキーマは何でもかまいません。スタックは (Azure Storage Blob を使用して) クラウドに簡単に移動し、必要に応じてほぼ無限のスケーラビリティを実現します。

詳細: http://abdullin.com/journal/2011/1/19/scalable-and-simple-cqrs-views-in-the-cloud.html

于 2011-02-25T11:57:34.787 に答える
1

私は WCF Data Services を使用して、読み取り側で多くの成功を収めました。私はそれについてブログ記事を書きました。http://blog.fossmo.net/post/WCF-Data-Services-A-perfect-fit-for-our-CQRS-implementation.aspxで確認してください。

于 2011-03-03T12:45:59.463 に答える
0

データベース内のストアド プロシージャで ADO.NET コアを使用しました。次に、私が作成したツールを使用して、各ストアド プロシージャの結果を Dtos の構造として使用して、すべてのデータ アクセス コードを生成します。

ソース コード付きのツールは、私のブログ Data Access Layer CodeGenで入手できます。

WCF サービスを介してデータを返すだけなので、DataReader から Dto に移動し、DTO をシリアル化する必要はありません。つまり、データを送信する過程で、結果セットを 3 回反復処理しています。そのため、サーバーのリソース使用率を減らしてパフォーマンスを向上させたい場合は、ツールが生成する "DataReader-Wrapper" クラスを (データ アクセス コードと共に) 使用できます。

DataReader ラッパー クラスは、厳密に型指定された DataReader に似ています。これらとその利点について話している別の投稿があります DataReader Wrappers - TypeSafe

もちろん、ツールを変更して (ソース コードも持っているため)、WCF サービスを含むすべてのコードを生成することもできます。したがって、ストアド プロシージャを記述するだけで、完了です。すべての DataAccess コード (ADO.NET Core を使用しているため、軽量で超高速です)、ビジネス レイヤー コード、および WCF コードは、私が言いたいことを理解すれば、実際には「忙しい作業」です。

EDIT ストアド プロシージャを使用する理由

  1. ストアド プロシージャは、1 回の呼び出しで複数の結果セットを返すことができます。
  2. ストアド プロシージャは、パラメーターを受け入れることができます。
  3. ストアド プロシージャには制御フロー ステートメントを含めることができ、他のストアド プロシージャを呼び出すことができます (そのため、他の複数のメソッドから呼び出すことができるように、メソッドをリフェクトするようなプロシージャの再利用が可能になります)。
  4. ツールはストアド プロシージャと非常にうまく連携するため、ストアド プロシージャの最適化ははるかに簡単です。
于 2011-02-25T11:40:26.927 に答える