WCF別のベストプラクティス？

Question

私はWCFサービスを構築し、その機能は素晴らしいです！しかし、私はこれを既存のソフトウェアに実装しようとしています。私は即座に質問に取り掛かります。プロキシ生成コードを使用して、最初に使用したDLLを取り除くのですか？あるいは、私は両方を保ち、2つの区別を非常に明白にしますか？

私が区別を保持することは、同じユーザーオブジェクトを表すServerUserとLocalUserプロパティを持つことです。しかし、アプリケーションサービスが利用できない場合、私のLocalUserプロパティは、アプリケーションが最初に実行したdllによって埋められます。

私の主な理由は、私のDLLを削除すると、私は単一の障害点があるという考え方です。何らかの理由で私のServiceHostが稼働していないだけで、DBサーバーが稼働していれば、私は自分のユーザーが依然として仕事をしてくれることを望んでいます。新しいWCF実装が利用する機能は、従業員が仕事をすることに依存しません。これは、WCFサービスが提供する便利な機能です。また、この種のロジックをサービスに組み込むことで、非IISホスト環境でのサービス変更をより容易に利用できるようになります。

また、ServiceHostが利用できない場合に手動でDBにアクセスすることを知っているクライアントのプロキシコードをプルダウンするときに、サービスのロジックを構築する方法はありますか？これが可能であれば、私の問題の90％は消えてしまうと思います。

ありがとうございます！

Answer 1

あなたの説明によれば、既存のDLLを維持する、つまりDBに直接アクセスできるように思えますから、ニーズに最適です。 WCFサービスを使用すると、失敗した場合でも、DLLを使用するだけです。

理想的には、WCFサービスを完全に利用し、潜在的なサービスの問題に対処するために何らかの冗長性を提供することが理想的です。さらに、サービスを使用すると、DLLのアップグレード/展開を処理する必要がなくなります。

しかし、ご質問からは、サービスが利用できない場合に対処するためのいくつかの実際の問題があるように聞こえるので、DLLを使用してください。

編集：ちょうどあなたの質問の最後の部分を読んで、私はそれが可能だとは思わない。プロジェクトに参照を追加すると、サービスにアクセスするためのプロキシコードが生成されます。あなたが後にしている「ダイナミック」な情報は実際にはサービスを必要とします。

EDIT：以下の私のコメントをフォローアップすると、DLLとクラスを作成することでこれをテストでき、Class1と呼ぶことができます。 Class1を返すメソッドでWCFサービスを作成します。クライアントアプリケーションを作成し、そのサービスへの参照を追加します。プロキシで生成されたコードを見ると、うまくいけば（これは私がタイプしたときに考えている:)）メソッドはClass1を返しますが、コンパイルするとClass1を見つけることができません。これは、Class1にはクライアント上でClass1を自動生成するDataContractAttributeがないためです。したがって、共有DLLをクライアントに配布する必要があります。メソッドが返され、WCFがClass1を再作成しようとすると、共有DLLのローカルバージョンが使用されます。すでにクライアント上にある他のDLLは、同じ共有DLLを使用します。