WCFサービスとビジネスロジック

Question

私は自分のビジネスロジックをどこに配置するかわからない。私はその方法をクライアントに公開するWCFサービスを持っています。

私のビジネスロジックはサービス方法に進む必要があります

public User GetUser(int id)
{  
     //Retrieve the user from a repository and perform business logic
     return user;
}

または、各WCFサービスメソッドがビジネスレイヤーメソッドを呼び出す別のクラスである場合。

public User GetUser(int id)
{  
     return _userLogic.GetUser(id);
}

Answer 1

私の個人的な好みは、WCFを別のビジネス層の上に非常に薄い層として持つことです。 WCFレイヤーは、オプション2で示したものと同様に、ビジネスレイヤーに電話をかける以外に何もしません。 、WCFを介してではなく、ビジネスレイヤーを直接呼び出すWPFアプリケーション）。

Answer 2

WCFサービスは、デフォルトで再利用用に設計されています。私はあなたのサービスにいくつかの論理を持たない理由はないと思いますが、単一の責任の原則のようなことを念頭に置いてください。

それでも、機能性を小規模なクラスに分割することになった場合、これらのクラスをWCFサービスとしてホストすることはまったく悪い考えではありません。その後、必要に応じて（パイプ経由）、またはマシンの境界（TCP）を越えて、またはWebサービスとして使用することができます。必要に応じてファサードを作成して、他の小規模なサービスの機能へのアクセスを提供します。

WCFサービスクラスにロジックを置くことを避ける必要はありません。

Answer 3

この決定はあなたのビジネスのニーズに依存していると思います。 WCFは、サーバーとクライアント間でデータ（オブジェクト）を輸送するメカニズムです。 businsessロジックがサーバーで実行されている場合は、ビジネスロジックを実行した後にWCFがオブジェクトを公開するようにする必要があります。

Answer 4

別のクラスのセットに入る必要があります。 WCFレイヤーには、サービスの製品の配信方法に関する直接的なロジックのみを含める必要があります。

あなたの場合、ユーザーを返すWCFメソッドがあることがわかります（これはカスタムクラスだと思います）なぜユーザーオブジェクトを返す一部としてそのプロパティを入力するのではなく、ユーザーIDを返す別の方法があるのですか？

Answer 5

再利用/テスト可能性/メンテナンス/読みやすさのために、常にBLを別のレイヤーに入れる必要があります。