3

私は Web サイトのバックエンドを書き直している最中であり、それを 3 層アーキテクチャーに移行しています。

私の意図は、次のように構成することです。

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

私の問題は、この構造内に DTO を配置することです。DTO を使用して、ビジネス層と WCF サービスの間、および WCF サービスから消費 Web サイトにデータを移動する必要があります。

ここでの調査中に、いくつかの優れた議論を読みましたが、頭を少し悩ませていました。

  • Davide Piras はこの投稿でいくつかの素晴らしい点を述べています。私がこの設計に従うとしたら、別のプロジェクトで POCO のインターフェイスを宣言します。これらは、層 (1) および (2) によって実装されます。私はインターフェイスの使用が好きですが、(1) と (2) で POCO を宣言し、AutoMapper のようなものを使用してそれらのデータを前後にコピーすることで、より多くの作業を自分で行うように思えます。

  • この投稿では、すべての層から参照されるビジネス オブジェクト プロジェクトが作成されるシステムを使用します。これは他のソリューションよりも単純なようで、次のようなソリューションにつながるようです

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

^               ^                       ^
|               |                       |
[ -- Business Objects Referenced here --]

私の質問は次のとおりです。ソリューションの 3 層にわたってビジネス オブジェクトを共有するコードの匂いはありますか?それとも、上に挙げた 2 つの方法は、同じナットをクラックする 2 つの異なる方法にすぎませんか?

4

2 に答える 2

2

UI (Web サイト) とサービス (WCF + BL + DAL) を 2 つの異なるエンティティと考えてみましょう。

  • 両方を 100% 制御できる場合は、アプローチ #2 を選択する必要があります。これは、UI レイヤーでの WCF プロキシ オブジェクトとビジネス オブジェクト間の変換が回避されるためです。

  • それ以外の場合は、エンティティの 1 つが一種の「ブラック ボックス」であり、外部の利害関係者によって変更される可能性があるため、アプローチ #1 を使用することをお勧めします。そのため、ビジネス オブジェクトの内部セットを保持する方が安全です。これには、ビジネス オブジェクトと WCF プロキシ オブジェクト間の変換が必要になります (拡張メソッドまたはトランスレータ フレームワークを使用)。

ここで、UI レイヤーの複雑さやその実装 (MVC、WebForms など) が正確にわからないため、特定のオブジェクトを表示する必要がある場合と必要でない場合があります (データバインディングの軽量化、JSON へのシリアル化の高速化など)。このオブジェクトを と呼びますModel。

  • 個別の UI 固有が必要ない場合はModel、ビジネス オブジェクトをDataContract(WCF のコンテキストで) としてマークし、レイヤー間で使用することをお勧めします。SerializableWeb 経由で WCF を呼び出しているかのように、エンティティを明示的にマークすることを忘れないでください( $.ajax)。

  • それ以外の場合は、サービスで使用し、UI レイヤーでDataContract変換するDataContractトランスレーターを使用します。ModelここではAService Adapterが適しています。これは UI レイヤーにあり、WCF サービスの使用と と の間の変換を担当しDataContractますModel。UI レイヤーで を使用できますService Proxy。これは、WCF サービスのラッパーであり、Web で使用できます。

最後に、データ層のビジネス オブジェクトへの参照が不足していませんか? データ レイヤー自体のデータ ストアからビジネス オブジェクトを設定すると思います。

于 2012-07-17T16:15:30.397 に答える
2

多くの場合、構築しているプロジェクトの複雑さに依存すると思います。私が構築した小規模なプロジェクトでは、レイヤー全体で「エンティティ」（単純な DTO、ゲッターとセッターを備えたシリアライズ可能なデータ バケット）を共有しましたが、これについてはあまり気にしませんでした。最大の欠点の 1 つは、ロジックがプロジェクト全体 (「ビジネス層」だけでなく) に散らばり、手続き型のスタイルになったことです。これは本当に貧血ドメイン モデルのように見えますが、プロジェクトが大きくなりすぎなかったため、複雑さが忍び寄ることはありませんでした。Entity Framework には、エンティティをそのまま構築できるいくつかのテンプレートがあります (私が間違っていなければ、それらはセルフ トラッキング エンティティと呼ばれますか?)。

中規模または大規模なプロジェクトでは、このアプローチは使用せず、エンティティと DTO は異なる役割を果たしているため、別々に保持します。DTO はエンティティとはまったく異なる形をしている可能性があり、それらを層/レイヤー間で共有しようとすると、しばしば臭いがします。

于 2012-07-17T11:29:09.630 に答える