クライアントアプリvs Windowsサービスvs？

Question

私は現在、私たちの組織のための一連のアプリケーションのためのいくつかの再アーキテクチャを検討しています。私たちは現在、お互いに通信し、クライアントソフトウェアとハ​​ードウェアの間に中間レベルを提供する、10-15の奇妙なスタンドアロンアプリケーションを用意しています。

現在のモデルの問題は、メモリオーバーヘッド、通信遅延、システムの肥大化、これらのアプリケーションがクラッシュした場合の問題からの回復を困難にする、多くの個別のアプリケーションの問題です。

私は、これらの問題のいくつかに対処するのに役立つ1-2の論理ユニットにアプリケーションを組み合わせることを考えています。ジレンマはよくこれを行う方法である：

• Windowsサービス
• UIアプリケーション
• どちら？

目標は、すべてのクライアント - ハードウェア通信を処理する常時システムを持つことですが、このシステムの個々のコンポーネントすべてと通信できるリッチな管理ユーザー設定UIも備えていますconfig/etcの機能を提供します。 WinForms/WPFアプリケーションを使用すると、管理者がシステム設定に簡単にアクセスできるようになり、リアルタイムフィードバック（カメラフィードなど）が提供されますが、管理者が誤ってウィンドウを閉じてしまうことがあります。その作業をすべてやっているサービスは素晴らしいですが、このサービスをやりとりしたり変更したりするリッチな管理ユーザーUIを提供する方法についてはわかりません。

お読みになりたいアイデアやリンクはありますか？

ありがとうございます！

Answer 1

似たような質問をしている可能性のある他の人のために私自身の質問を更新すると思っていました。

私が行ったのは、いくつかの子コンポーネントのWCFエンドポイントの数を公開する集中型Windowsサービスです。その上には、WCFエンドポイントを介してWindowsサービスと通信するUIアプリケーションがあります。ビルド&のデバッグを容易にするために、Windowsサービスはデバッグ時にコンソールアプリケーションとして実行するように設定されています。

これまでのところ、このソリューションは素晴らしいと思われます。