0

私は金融アプリケーションを扱っており、アプリケーションを設計するための最適なソリューションを探しています。

ビジネスロジックのほとんど/すべてが置かれている数百のストアドプロシージャがあります。Web Service Software Factory (http://servicefactory.codeplex.com/) を使用して構築された WCF Web サービス プロジェクトがあります。ほとんどすべてのもの (テーブル、ドロップダウンなど) 用に構築されたストアド プロシージャがあり、これらのストアド プロシージャにはそれぞれ、Web アプリケーションによって呼び出されるように公開された独自の Web サービスがあります。各 Web サービスは、Web サービスの正確なパラメーターを使用してストアド プロシージャを呼び出す非常に単純なメソッドです。

これが最良のデザインであるかどうか確信が持てないため、デザインの提案や代替案を求めたい.

似たような環境の人は他にいますか？それはあなたの側でどのように実装されていますか?

4

2 に答える 2

2

これは、次の間の古典的なトレードオフです。

  • 1 つのことを 1 つのことだけを行う小規模で焦点を絞ったサービスを用意すると、多くの「それら」ができあがります。
  • 多くのことを行う多くのメソッドを備えた大規模なサービスを持っていますが、それらの数は少なくなります

一般的に、私はアプローチ 1 を好むと思います。つまり、サービスを適切で小さく維持しやすくし、単一責任の原則を尊重します。つまり、サービス (ま​​たはクラス) は 1 つのことだけを実行する必要があります。

論理的に一緒に属するいくつかの呼び出しを、いくつかの呼び出しで 1 つのサービスに結合できる場合があります。非常に多くのタスクを処理するため、頻繁に変更する必要があります....

于 2010-10-04T05:14:34.337 に答える
1

私の見解は、サービスの使用目的に基づいています。サービスは外部アプリケーションのサーバーに送信されるのでしょうか、それともアプリケーション内でのみ使用するためのものでしょうか?

アプリケーション内で使用する場合、私はプロセス外層 (たとえば、CRUD タスクを実行するサービス層など) ではなく、プロセス内のチャット層を使用する傾向があります。前者はパフォーマンスの観点から非常に優れており、複数の Web サーバーなどを使用することでスケーリングが可能です。同じインプロセス レイヤーを複数のフロントでホストできます。たとえば、アプリケーション UI に使用される Web アプリ、日常業務を行うコンソール アプリ、WCF などです。サード パーティなどによって消費されるサービス。トランザクション管理とフロー コンテキスト情報は、インプロセス レイヤーで簡単にすることができますが、WCF サービス レイヤーでは可能ですが、非常に高価です。

外部コンシューマーにとって、WCF サービスは大きなフロントですが、サービス インターフェイスは分厚い必要があり、ビジネス用語から厳密に機能を公開する必要があります (たとえば、永続化を目的とした CRUD メソッドではなく、ドメインから意味のあるメソッドを含める必要があります。CreateOrder など)。複数のテーブルにエントリを作成します)。

于 2010-10-04T06:05:10.263 に答える