したがって、通常、中間層はビューア/ブラウザ用の Web ページを生成します。
私はこれに少し同意しません。中間層は、ビューで使用できるデータを生成すると思います。ビューは、ASP.NET WebForm、ASP.NET MVC Razor ビュー、または C# デスクトップ アプリケーションの WinForm である可能性があります。
データとビューの真の分離が必要な場合は、システムのバックエンドを、Web サイト/Web アプリケーションまたはデスクトップ クライアント/バイナリなどで使用できる Web サービスにすることを検討する必要があります。
SQL DB + ファイル システム -> ビジネス ロジック/中間層 -> ビュー (Web/デスクトップ/モバイル)
最初のビューの実装は、デスクトップ C# バイナリ ビューになります。
さらに重要なことに、更新/通知を DB から midtier にプッシュし、次に c# アプリにプッシュするにはどうすればよいですか ???
これに基づいて、C# アプリケーションに更新を即座に受信させ、アプリは Web アプリ (HTML/JS など) ではありませんが、実際には Web クライアントであると想定しています。
このような通知は、いくつかの方法で達成される傾向があります。
- HTTP ポーリング
- HTTP ロングポーリング
- HTTP ストリーミング
- WebSocket
後者は現在、クライアントとサーバー間のリアルタイム双方向全二重通信の標準です。ただし、更新の頻度が非常に低い場合は、C# クライアントが長い間隔でポーリングして更新を確認できる Web サービスを単純に実装できます。
更新頻度が妥当であり、プッシュ通知の要件が妥当であると示唆している場合は、リアルタイム プッシュ システムをお勧めします。そのため、WebSocket サーバーとクライアントを使用することをお勧めします。次のような WebSocket サーバーとクライアントの例が多数あります。
独自のリアルタイム メッセージング インフラストラクチャを実装してホストする必要性をなくしたい場合は、ホステッド リアルタイム サービスを検討できます。