私は、ユーザーが電子メールでコンピュータにコマンドを送信できるようにするアプリケーションを構築しています。サーバーは1つ以上の電子メールアカウントを監視（プル）し、通信セッションを開始します。いくつかの認証も関係しています。私は最新かつ最高の.net技術を使用しています。サーバサービスとGUIのアーキテクチャは何ですか？
私はサーバーをサービスとして公開しようと考えていますが、ユーザーがパスワードや電子メールアカウントなどの設定を行えるようにGUIを設定することはできません。どのようにこれらを分けることができますか？
第2に、コマンドはプラグイン可能であり、独自のGUIを提供する必要があります。これをどのように組み込むことができますか？サーバー・プロセスはコマンド機能を使用できる必要があり、GUIプロセスはカスタマイズを可能にすべきです。
私はWCFを使用しました.WCFは、WebサービスやSOAを実装するためのMicrosoftの現在の技術です。 WCFサービスを呼び出すデスクトップクライアントまたはWebページを作成します。 WCFサービスはサーバーコンポーネントになり、デスクトップクライアントまたはWebページはユーザーのフロントエンドになります。
サービス自体を作る方法は、主に問題ではありません。通信プロトコルは主要な問題ではありません.WCFでは、プロトコルの幽霊を通してアプリケーションのメソッドを公開することができます。これは単なるアプリケーション構成の問題です。
ここでの主な質問は、GUIを実装する方法です。アプリケーションが通常のWindowsサービスの場合、組み込みのGUIは使用できません。サービスはそれを持ってはならないからです。したがって、別のGUIアプリケーションが必要になります。オプション：
GUIはスタンドアロン.NETアプリケーションで、サービスと何らかの形で通信します。 WCF経由で言うとしましょう。この場合、プラグインはサービス用のプラグインとGUI用のプラグインの2つの部分で実装する必要があります。私はそれがサポートするには複雑すぎると思う。
第1変種の変更。サービスとGUIの両方が1つの実行可能ファイルにまとめられています。起動したモード（サービスまたはスタンドアロン）を調べ、メールを監視したりGUIを表示したりします。これは1つのアプリケーションなので、構成も同じです。だから、あなたはプラグインのための単一のレジストリを持つでしょう。私は、GUIモードのアプリケーションでは、開始されたサービスを検索し、それを設定すると仮定します。欠点 - GUIはローカルでのみ実行できます。
あなたはある種の「転送可能な」GUIサービスを作成して、それを示す簡単なクライアントにGUIを送信します。この場合、すべてのアプリケーションコード（サービスとGUI）の場所は1つですが、一部はサービスで、一部はクライアントソフトウェアで実行されます。しかし、そのようなユニバーサルクライアントソフトウェアも必要です。
もう少し考えてみると、このソリューションは既に存在しています。それはWeb技術です。 Webサイトの一部としてサービスを実装するのが最も簡単です。 GUIもまた別の部分です。 HTMLとJavascriptに精通していない場合は、Silverlightを使用してGUIを実装できます。
実際、サービスでASP.NETをホストすることができます。 Here is the good explanation。しかし、私はそれが不必要な複雑さを加えることを恐れます。
ユーザのフロントエンドは常に同じマシンにあります。 WCFを使用するのは理にかなっていますか？私は.netリモートIPCチャンネルを介して通信することを考えていました。 –
@Bogdan：WCFでIPCを使用できますが、WCFはリモーティングに代わるものです。 –
優れたビデオシリーズを十分なページでクリックすると、各ウェブキャストのビデオをダウンロードできます。 http://www.dasblonde.net/2007/06/24/WCFWebcastSeries。aspx – AaronLS