0

データベースのやり取りとビジネスロジックを担当するwcfサービスがあります。ビジネス オブジェクト用のクラス ライブラリもあります。wcf サービスがオブジェクトのリストを返すようにします。asp .net プロジェクトがオブジェクト タイプを理解できるように、(サービスを消費している) asp .net プロジェクト用にビジネス オブジェクトの別のクラス ライブラリを作成する必要がありますか?

4

3 に答える 3

2

サービスとasp.netプロジェクト間でクラスオブジェクトライブラリを共有する必要があります。これは、プロジェクト全体の「ミドルウェア」のようなものです。そうすれば、不必要な重複を避けることができます。基本的に、すべてのビジネスオブジェクトを別のプロジェクトに移動し、それをwcfソリューションとasp.netソリューションの両方に含めます。

于 2012-04-05T06:07:28.243 に答える
1

あまり。VisualStudioを介してAddServiceReferenceを使用してWebサービスへの参照を追加すると、Webサービスで使用されるすべてのオブジェクトのプロキシクラスが取得されます。

于 2012-04-05T06:06:25.130 に答える
1

サービスの標準的な方法は、ビジネス オブジェクトの代わりにDTOを返すことです。プレゼンテーション レイヤーでビジネス オブジェクトを使用すると、ビジネス ロジックと密接に結び付きますが、ほとんどの場合、この種の結び付きは望ましくありません。また、ネットワーク上で送信するものはすべてシリアル化できる必要があり、ビジネス オブジェクトはシリアル化できる場合とできない場合があることに注意してください。

したがって、おそらく、DTO を使用して別のライブラリを作成し、その中のクラスをデータ コントラクトとして使用することをお勧めします。重複は、コントラクトの一定の安定性を保証し、 AutoMapper などのツールを使用してビジネス オブジェクトを DTO にマップできるため、実際には問題になりません。

プレゼンテーション (ASP.NET) とサービス層の間で共通のビジネス クラス ライブラリを共有するアプローチの長所と短所を考えてみましょう。

長所：

  • 実装が簡単: 既存のプロジェクトを asp.net に接続し、クラスをシリアル化可能としてマークするだけで完了です。
  • 非冗長: 概念を表すクラスが 1 つあります。

短所：

  • あなたのクラスは直列化できないかもしれません
  • サービスを介さずに、プレゼンテーション層で直接使用することになっていないビジネスクラスを「スリップ」して使用するのは非常に簡単です
  • 密結合: ビジネス クラスを変更すると、サービス層とプレゼンテーション層の両方が壊れる可能性があります
  • なぜ私たちは再びサービスを利用しているのですか?

これを DTO ライブラリの作成と比較してください。

長所：

  • インターフェイス (データ コントラクト) が明確に定義されている: このライブラリにあるものはすべて通信オブジェクトです
  • シリアライズも問題なし
  • プレゼンテーションとサービス間の疎結合: データ コントラクトの抽象化の助けを借りて、ビジネス ロジックの変更は最大で DTO マッピング レベルまで反映されます。

短所：

  • オブジェクトを DTO にマップする必要があります (これには AutoMapper が非常に役立ちます)。
  • Dmitriy は複製を引用しましたが、不必要は主観的ですが、なぜそれが必要なのかを説明したと思います。さらに、アプリケーションのさまざまな部分で使用するために、同じ概念のさまざまなビューを導入することを恐れてはなりません。重要なプログラムのすべてのユースケースに完全に適合するモデルをまだ見つけていません。
于 2012-04-05T06:49:34.480 に答える