2012-05-12 15 views
0

私のWCFアプリケーションはUIからRequestContextを受け取り、DBからデータを取得する前に3つのレイヤーを持っています。つまり、BusinessLogicLayer、FacadeLayer、およびDataAccessLayerです。私は各レイヤーでそのRequestContextオブジェクトで動作するdifferntクラスを持っています。私は私のRequestContextのはIRequestContextを実装/または任意のでしょうここで、私は、オブジェクトを受け取るために具体的なクラスを持っておりますのでnew Facade(RequestContext rqstContext)BusinessLogicレイヤーからDataAccessLayerファサードへの依存性注入

のようなそのコンストラクタ何かスルー各レイヤのクラスにRequestContextのオブジェクトを渡し、new Facade(IRequestContext rqstContext)のようなものを持っていることがベストプラクティスですしています抽象クラス?

答えて

0

OO(オブジェクト指向)とSO(サービス指向)の間で混同しないでください。あなたの説明から、RequestコンテキストクラスはDTO(データ転送オブジェクト)のようです。あなたのエンティティが純粋にデータを転送するために使用されている場合、それを再因子付けしてインターフェースする必要はありません。

+0

下位レイヤがウェブ関連の上位レイヤ(特にHTTP関連、例えばHttpContextとRouteDataなど)に依存することを除いては何ですか? –

+0

あなたは読まれましたか?彼は彼のカスタムメイドのエンティティをRequestContextと呼んでいると言っています。彼はSystem.Web.Routing.RequestContextを使用していません。 –

+0

System.WebからのRequestContextに基づいています - 本当にHttpContextとRouteDataしかありません。独自のインターフェイスを作成することでSystem.Webを抽象化することができますが、元のクラスはWeb固有のままです。 –

1

フロントエンドがWebアプリケーションであるため、BusinessLogicLayer、FacadeLayer、およびDataAccessLayerを結合していますか?これはレイヤリングの目的を破るものです。ベストプラクティスは、フロントエンドがWebであり、必要なRequestContextプロパティの部分だけを渡すという抽象的な事実です。

+0

提案していただきありがとうございます。私はあなたを得ていない。申し訳ありません –

+0

WPFであるフロントエンドを追加した場合、RequestContextに似たものはもうなくなります。あなたの他の層が(たとえインターフェースによって抽象化されていても)RequestContextに依存するという事実は、それらがWCFフロントエンドに依存していることを意味します。彼らはそれらの上の何かに依存しているので、もはやレイヤーではありません。 –

+0

これに解決策がありますか? –