2

私は WCF の学習を始めたばかりで、まったく Web 以外のバックグラウンドを持っています。

ローカルで実行される 1 つの exe にコンパイルされる 3 層のデスクトップ アプリケーションを構築しました。

ここで、ビジネス ロジック レイヤー全体を中央サーバーに移動し、GUI をクライアント アプリケーションにしたいと考えています。

私が理解している限り、WCF は私のソリューションである必要があります。実際、WCF は私が望んでいたことを達成するのに役立ちました。

私は必要なものの基本であるリモート機能を実行することができます。

私の問題は、私がアーキテクチャをよく理解していないことです。

たとえば、私のサービスの 1 つは、ビジネス ロジック層からデータ型 (クラス) を返します。

このクラスは、WCF メカニズムを介してクライアントが自動的に使用できるようになります。

しかし、問題は、このクラスにはいくつかのメソッドが含まれていることです。これらのメソッドをクライアントに公開したくないことは間違いありません。

たとえば、Save メソッド (データベースに保存)。

さらに、このクラスは私のサービスの 1 つに送信される可能性があるため、クライアントがクラスのすべてのプロパティを変更することを許可したくない場合もあります。

サービス内のクラス インスタンスを再検証したくありません。

私は何をすべきか？クライアントに公開するビジネス ロジックの制限されたバージョンの別のレイヤーを構築する必要がありますか? または、サーバー自体を制限せずに、クラスの一部のみをクライアントに公開する方法はありますか?

これが基本的な質問であることは知っていますが、正直なところ、ここで質問する前にたくさん検索しました。私の問題は、何を検索すればよいかよくわからないことです。

2 番目の質問は、このアーキテクチャを説明できるリソースの推奨事項はありますか?

4

3 に答える 3

8

通常、ビジネス層をカプセル化する場合、ビジネス オブジェクトを直接公開することは望ましくありません。これは、分離されたクライアントがあり、ビジネス ロジック/プロパティが変更されるたびにクライアントを更新する必要がないためです。

ここで、データ転送オブジェクト (DTO)がうまく機能します。通常、公開するコントラクト (データとメソッド) を制御する必要があります。したがって、転送層を構成する他のオブジェクト (DTO) を明示的に作成します。その後、クライアント コードとサーバー コードを個別に安全に変更できます (両方がコントラクト オブジェクトを満たしている限り)。

これには通常、(それぞれの側で送信または受信する前に) もう少しマッピングが必要ですが、多くの場合、それだけの価値があります。

WCF の場合、 でマークされたインターフェイスとクラス、および でマークされた[ServiceContract]クラスは、[DataContract]通常、この転送レイヤーを構成します。

于 2012-08-11T15:56:08.980 に答える
1

メソッドをクライアントに公開する WCF では、OperationContractAttribute でマークする必要があります。したがって、クライアントに Save メソッドを使用させたくない場合は、この属性でクライアントをマークしないでください。

詳細はこちら: http://msdn.microsoft.com/en-us/library/system.servicemodel.servicecontractattribute.aspx

プロパティとほとんど同じですが、異なる属性: DataMemberAttribute です。クライアントに表示されない場合は、それでマークしないでください ( DataMember 属性)

于 2012-08-11T15:03:23.793 に答える
0

しかし、問題は、このクラスにはいくつかのメソッドが含まれていることです。これらのメソッドをクライアントに公開したくないことは間違いありません。

クラスとインターフェイスのコードの例を提供できますか? もしそうなら、あなたはより具体的な答えを得ることができると確信しています。

たとえば、Save メソッド (データベースに保存)。

考えられるアプローチの 1 つは、クラスを 2 つのクラスに分けることです。最初のクラスでプロパティを定義し、そのクラスを 2 番目のクラスの基本クラスとして使用します。次に、2 番目のクラスを使用してメソッドを定義します。これにより、コードを DRY に保ちながら、プロパティのみを返すことができます。

さらに、このクラスは私のサービスの 1 つに送信される可能性があるため、クライアントがクラスのすべてのプロパティを変更することを許可したくない場合もあります。サービス内のクラス インスタンスを再検証したくありません。

各プロパティの get メソッドと set メソッドでロジックを定義できますが、サービス間で受信した入力を再検証することを強くお勧めします。これは、1 つのサービスで将来変更やエラーが発生すると、アプリケーション全体でより大きな問題が発生する可能性があるためです。さらに、これは、アプリケーションが潜在的な攻撃に対してより安全であることを保証するのにも役立ちます。

クライアントに公開するビジネス ロジックの制限されたバージョンの別のレイヤーを構築する必要がありますか? または、サーバー自体を制限せずに、クラスの一部のみをクライアントに公開する方法はありますか?

インターフェイス内のデータおよびメソッド属性を使用して、さまざまなプロパティおよびメソッドへのアクセスを制限できるはずであるという上記の回答に同意します。

2 番目の質問は、このアーキテクチャを説明できるリソースの推奨事項はありますか?

安価だが非常に価値のあるビデオ ベースのトレーニングを探しているなら、Pluralsight が提供するコースは、アーキテクチャと WFC サービスの両方に非常に適していることがわかりました (ちなみに、私は彼らとは関係がありませんが、彼らのトレーニングを楽しんだだけです)。

于 2012-08-11T21:19:00.020 に答える