このアーキテクチャには何か問題がありますか（MVC、Webservices、Winform）

Question

大規模なvb6/sqlデータベースアプリケーション（何百ものテーブル、クラス、フォーム）をC＃に移行したいと思っています。 、winformクライアント。そこで私は、集中管理するデータベースとビジネスロジックの多くはある、と私は私のWeb UIプラットフォームとしてASP.Net MVCを好むため、私は次のことを検討している：インクルードする

MVC Webプロジェクト：

永続性とPOCOオブジェクトを提供するために、MVCコントローラへ
• DALクラスをBLLサービスを提供するために、PhoneGapのアプリと豊富なhtmlページ
• サービスクラスにJSONオブジェクトを提供するためのWeb UI用
• MVCのWebコントローラとビュー
• MVCコントローラサービス利用/ BLL CLA sses
• サービスクラスをWinformアプリケーションに公開するWebサービス。彼らはPOCOオブジェクトを受け入れて返します。

Winformアプリケーションは、すべてのデータに対してWebサービスに大きく依存します。私は何百ものデータベーステーブルを持っているので、WebサービスはこのデータをPOCOオブジェクト（いくつかのネストされたPOCOオブジェクトのリスト）としてクライアントに返します。私は、1）WSDLが巨大になり、アプリケーションが増え、公開されるクラスの数が増えると（VSのチョークになりますか？）、2）Webサービスを介してPOCOオブジェクトを返すことがうまくいかない。私はwinform UIから直接SQLサーバーを呼び出すことに慣れているので、Webサービスを経由する可能性は、すべてがシリアル化されIISを経由するため、ボトルネックになるようです。

Btw、私はサービス層がMVC UI層から論理的に離れていることを知っていますが、それらを組み合わせて配置を簡単にしています。私はWCFが問題を解決すればそれも考慮したいと思いますが、私が知る限り、それは不必要な複雑さを加えます。

これらの懸念事項はありますか？他のアドバイスはありますか？

Answer 1

WinFormsが消費するサービスをどのように構築していますか？設定方法によっては、WCFの再検討が必要な場合があります。 BLLをWCFサービスに入れることができます。その後、MVCアプリケーション、WinForms、PhoneGapアプリケーションはすべてWCFサービスを使用できます。つまり、すべてのビジネスロジックのための単一の場所があります。巨大なPOCOを扱っておらず、非同期呼び出しを行っている限り、サービスを使用しているWinFormsアプリケーションに大きなパフォーマンス上の問題はないはずです。

ここでは、接続するクライアントに基づいて異なるエンドポイントを簡単に公開できるため、WCFは非常に便利です。 PhoneGapアプリケーションがRESTエンドポイントを活用できる間は、MVCとWinFormsアプリはバイナリインタフェースを使用できます。

サービスが大きくなりすぎることを心配している場合は、データベースの特定の部分で動作する複数のサービス、またはBLLにすでに存在する可能性のある他の論理的な分離に分割することも検討できます。

この時点でなぜWinFormsアプリケーションが必要なのでしょうか。あなたはウェブサイト上でできないことはありますか？ WPFやSilverlightを調べましたか？どちらもサービスとは非常に自然に動作します。