3

最近、かなりの数の Windows フォーム アプリケーション (データ入力アプリ、オフィス統合など) を設計してきました。常に論理層を念頭に置いて設計してきましたが、「中間層」のビジネス ロジック層は常に、デスクトップ PC (つまり、物理的なクライアント サーバー)。

より複雑なアプリケーションにアプローチするにつれて、代わりに物理的な中間層が欲しくなります。デスクトップ クライアントは要求をアプリケーション サーバーに戻して、ビジネス ロジック (定期的に変更される可能性があります) とインターフェイスを処理します。スケーラビリティや保守性など、Web アプリに本来備わっている要素を見逃しているように感じます。

他の WinForms 開発者が中間層の分離をどこまで行っているか知りたいです。

  • 中間層サーバーで実行する処理 (ある場合) はどれくらいですか?
  • WCF、リモーティング、Web サービスなど、どのような通信方法を使用していますか?
  • パフォーマンスはどの程度の要因であり、サーバーへのラウンドトリップはどのくらいの頻度で行われますか?

ビジネス ロジックを別の層に移動する利点はありますか? それとも、コンポーネントを PC 上でローカルにホストする方がより実用的ですか?

あるいは、これらの要因が関係している場合、顧客を完全に WinForms から遠ざける必要がありますか? Silverlight や AJAX を使用した ASP.NET などの代替手段があるため、WinForms クライアントを選択する理由は縮小しているようです。

4

3 に答える 3

2

心に留めておくべき重要なことは、個別の中間層を使用した開発の容易さと、スケーラビリティのすべてのメリットなどの間にはトレードオフがあるということです。これが意味することは、コード内のインターフェイス マッピングなどを更新する必要があるということです。 、テスターが使用できるように中間層をどこかに展開する必要があります。これは更新する必要があります。次に、すべての操作などに対して DTO を作成する必要があります。

このオーバーヘッドの一部は適切なビルド システムで処理できますが、セットアップと保守にも労力が必要です。

私の好みの戦術は、アセンブリに関して物理的な分離を維持し (つまり、個別のビジネス ロジック/データ アクセス アセンブリを持っている)、すべての呼び出しを、一連の Facade クラスであるインターフェイス レイヤーを介してビジネス レイヤーにルーティングすることです。したがって、これらのアセンブリはすべて、Windows アプリ内に存在します。また、これらすべてのファサードのインターフェースを作成し、ファクトリーを介してそれらにアクセスします。

そうすれば、中間層の分離が必要になり、生産性の面でのトレードオフが価値がある場合、ビジネス レイヤーを分離して、WCF サービスの背後に置くことができます (それが私の優先サービス プラットフォームであるため)。私のファサードが何を配布するか、そしてファサードが受け入れるもので何をするかに関して、いくつかのリファクタリングを実行します。

于 2009-08-13T08:39:07.410 に答える
1

これは、私が常に Web 環境で仕事をする傾向がある理由の 1 つの例です。クライアント アプリケーションがサービス呼び出しにネットワークを利用できる場合は、Web サーバーからデータを送受信するために利用できます。

確かに、クライアントの制限によって最終的なパスが変更される可能性がありますが、方向性に影響を与える機会が与えられた場合、私は Web ベースのソリューションに舵を切ります。従来のデスクトップ パッケージよりも簡単なアップグレード パスを提供する展開テクノロジがありますが、サーバー ベースのアプリケーションの更新に代わるものはありません。

于 2009-08-10T15:15:30.480 に答える
0

アプリケーションに応じて、覚えておくべきいくつかのパフォーマンスの問題があります。

さまざまなクライアント（共有データ）間で作業が非常に類似している場合は、キャッシュを利用して全体的な処理を削減できるため、中間層で処理を実行する方が適切です。

クライアント（プライベートデータ）間でデータが異なる場合は、中間層で処理を行ってもあまりメリットはありません。

于 2009-08-07T13:19:53.190 に答える